The situation
What needs investigation
A production application relies on MySQL, PostgreSQL, or a managed database that is growing in traffic and data volume. The review checks whether database architecture, application connections, backups, replica use, and recovery procedures support the workload.
Signals we look for
Workload
- read and write profile
- slow queries
- connection management
Availability
- Multi-AZ or replica design
- failover behaviour
- application reconnect logic
Data protection
- backup retention
- restore testing
- encryption and access
Operations
- storage growth
- I/O and latency
- database monitoring
How we investigate
Each step is validated against the workload before the next change.
- 01
Profile database use
Review query patterns, connection count, transaction behaviour, and growth.
- 02
Check availability
Test how application clients behave during failover and connection loss.
- 03
Review protection
Validate backups, restore timing, encryption, and access paths.
- 04
Inspect capacity
Compare storage, I/O, memory, replicas, and peak workload needs.
- 05
Tune carefully
Prioritize query, index, pool, or caching changes with clear expected effects.
- 06
Validate recovery
Rehearse restore and application reconnection procedures.
Architecture / decision path
Example engineering decision
Illustrative database finding — not customer data
Connection countreaches pool limit at peak
CPUmoderate
API errorsconnection timeout
Engineering interpretation
Database CPU can look healthy while the application exhausts its connection pool. Increasing the database class may not address pool sizing, leaked connections, or long-running transactions.
Possible next investigation
- Inspect pool wait time and connection lifecycle.
- Identify slow or long-running transactions.
- Review replica and caching opportunities.
- Test changes under representative concurrent load.
Trade-offs we consider
Replicas
Read replicas can reduce read load but add lag and routing decisions.
Connections
Larger pools can increase throughput but overload the database.
Backups
Retention and restore speed must reflect recovery requirements.
Scaling
A larger class may be correct, but only after workload evidence is clear.
What the engagement can produce
Typical outputs for this type of work
Scope depends on the environment and the problem being investigated.
- database workload profile
- availability and failover findings
- backup and restore validation plan
- connection management recommendations
- monitoring baseline
- capacity and growth plan