Slow apps are not always an app problem
Slow applications are often blamed on the app, but many times the real bottleneck is the database.
The incident that made me realise this
So we were have microservice-based architecture and our application was having some issues as the response was coming really slow.
So, whenever the application has these kinds of issues, we used to check the metrics of the application pods. But, it was working fine, and we realised this time our Database making noise, but we were not able to hear that.
We spent sometime by checking Metrics for our Databases and realised there were a lot of issues present in our DB, such as CPU going up due to heavy queries, full table scans, bad indexing and a lot of idle connections sitting there for long hours, where there should have some limit or time to close the sessions properly.
My simple checklist to investigate slow database issues
But there can be other issues while investing your entire DBs. So here is the step-by-step guide you can follow to investigate your slow application issues. 90% of the time, this will help you a lot.
- Traffic spike
- Connections
- CPU & memory
- Disk IOPS & latency
- Slow/heavy queries
- Locks
- Replication lag
- Cache hit ratio (if using Redis/Memcached as read cache)
Investigation is not enough. Fix the root cause
Investigation is fine, and doing RCA is also an amazing thing. But your work is to provide the long-term solution to increase the reliability of the application.
Work with developers and DBAs, not alone
This can’t be done without your developers/DBA.
Sit with them, optimise the connection pool and ask them to terminate the session after a particular time.
Help/Ask developers/DBAs to optimise the queries and record Slow/heavy queries from the DevOps side.
Things that usually fix most problems
Proper indexing is important. Missing or wrong indexes can cause full table scans, but too many indexes can slow down writes. Balance matters.
If you are using a managed Database with a proper cluster way, ask developers to use the Read Replicas endpoint for Select(Read) related queries(when your app is non-critical). Otherwise, your writer replica will choke and become a bottleneck for the entire team.
Observability is your best friend
You can track it down as soon as the issue comes by setting up the metrics and leveraging the tools like the kube-prometheus stack and configuring alerts on multiple metrics to reduce your investigation time.
Moreover, you can configure slow query logs, use APM tools like Jaeger and Datadog, along with DB dashboards.
Let me know your thoughts or your way to troubleshoot the DB.
🚀 Top Remote Tech Jobs — $50–$120/hr
🔥 Multiple Roles Open
Hiring Experienced Talent (3+ years) Only.
- Frontend / Backend / Full Stack
- Mobile (iOS/Android)
- AI / ML
- DevOps & Cloud
⏳ Opportunities Fill FAST — Early Applicants Get Priority!
👉 Apply Here
🚀 Enjoyed this content?
If you found it useful, don’t forget to 👏 clap, 🔄 share, and 💬 follow for more DevOps & Cloud insights.
💡 Want to discuss trending technologies in DevOps & Cloud?
- 👥 Join the community on Discord
- 🎥 I am on YouTube
- 🌐 Explore all my learning at One platform→ Aman Pathak
🤝 1:1 Mentorship
If you’re looking for personalised guidance in DevOps & Cloud (career growth, projects, real-world problem-solving), I’m opening limited slots for 1:1 mentorship. Drop me a DM to know more.
👉 Keep experimenting. Keep learning. Keep growing!