My most recent database investigation
I recently took over a very old custom internal product.
The symptoms looked like this:
→ RAM usage suddenly spikes
→ CPU stays mostly fine
→ The app becomes slower and slower
→ A restart fixes it temporarily
What helped was not restarting faster.
What helped was understanding all the different things that can cause database bottlenecks, and ruling them out one by one.
A solid investigation pattern
This is the order I follow now.
1. Start with user symptoms
Before dashboards, ask:
→ Is the app slow, unavailable, or timing out?
→ Does it degrade over time or fail suddenly?
→ Does a restart help?
This already hints at memory, connections, or long transactions.
2. Check CPU
High CPU usually means too much work.
→ Constantly high CPU
→ Spikes during peak usage
Often caused by inefficient queries or missing indexes.
3. Check memory (RAM)
Important rule:
High RAM usage alone is not always bad.
Databases intentionally use memory for caching.
It becomes a problem when:
→ RAM keeps growing and never drops
→ Performance degrades over time
→ Swapping starts
→ Restarts fix things
4. Check connections
Very common in internal tools.
→ Too many open connections
→ No pooling
→ Connections not released properly
This often explains RAM pressure with normal CPU.
5. Look at queries
Only now do we zoom in.
→ Long-running queries
→ Queries pulling too much data
→ Missing indexes
6. Look at disk and I/O
Especially relevant for older systems.
→ Slow reads or writes
→ Batch jobs impacting users
→ Backups causing slowness
7. Look at locking and transactions
If performance feels random:
→ Queries waiting on each other
→ Writes blocking reads
→ Long transactions holding locks
The top 10 database bottlenecks explained simply
These are the ten most common ones PMs usually run into.
1. Inefficient database queries and indexing
Queries do more work than necessary.
Shows up as:
→ Slow responses
→ High CPU
→ Timeouts
|
|
|
2. Slow disk I/O
|
|
The database waits too long to read or write data.
Shows up as:
→ Slowness even with low CPU
→ Problems during heavy writes or reports
|
3. Network latency
The database itself is fine, but data travels slowly.
Shows up as:
→ Delays between app and database
→ Inconsistent response times
|
|
|
4. Locking and concurrency issues
|
|
Queries block each other.
Shows up as:
→ Random slowdowns
→ Requests waiting on other requests
|
5. Scaling and load limitations
The database cannot handle the current load.
Shows up as:
→ Performance drops under traffic
→ Spikes cause failures
|
|
|
6. Resource contention
|
|
Multiple workloads fight for the same resources.
Shows up as:
→ Unpredictable performance
→ Spikes without a clear cause
|
7. Inefficient data models
The schema makes queries more complex than needed.
Shows up as:
→ Too many joins
→ Hard-to-optimize queries
|
|
|
8. Unoptimized data retrieval
|
|
Too much data is fetched.
Shows up as:
→ Slow pages
→ High memory usage
|
9. Inadequate caching
The same expensive queries run again and again.
Shows up as:
→ Repeated database load
→ Slow responses for common actions
|
|
|
10. Long transactions
|
|
Transactions stay open too long.
Shows up as:
→ Locks
→ Cascading slowdowns
→ Other queries waiting
|
Is this actually part of my PM job?
I know, I know.
Digging into database and technical topics does not sound fun to everyone.
And you might be thinking:
Why am I doing this as a product manager?
Here is the reality.
If you have experienced developers and operations engineers on your team, and they can quickly troubleshoot, explain what is happening, and recommend the right fix, perfect. Let them do it.
But many internal PMs do not work in that setup.
Sometimes:
→ the team is understaffed
→ the most experienced engineer is on vacation
→ you are working with vendors
→ or you inherited a legacy product with very little context
And suddenly, you are the first line of investigation.
In those moments, knowing these basics helps you:
→ ask the right questions
→ collect the right signals before restarting systems
→ avoid panic-driven decisions
→ and move the conversation forward instead of blocking it
There is another benefit people often overlook.
Understanding database bottlenecks also changes how you work before things break.
It influences:
→ how you design new features with engineering
→ how you think about performance and scalability
→ how you prioritize and explain technical debt
→ and where you push for improvements early, instead of firefighting later
You do not need to become a database expert.
But having this mental model makes you a much stronger PM in real internal environments.
Summary: database bottlenecks, symptoms, and fixes
Summary: database, symptoms, and fixes
You can download the whole table from my Notion page here.
