Database monitoring is the practice of tracking the health, performance, and capacity of the databases behind an application. The database is where slowdowns concentrate: most app-level latency problems are a query, a lock, or a connection pool underneath, which makes this the highest-leverage layer of infrastructure monitoring to get right.
Definition: What Is Database Monitoring?#
Database monitoring continuously collects signals from database servers (query latency, connections, replication, resource use) and alerts when they degrade. Where server monitoring watches the host, database monitoring watches the engine running on it, because a healthy host can still serve a miserable database.
Key Metrics#
| Metric | Why it matters |
|---|---|
| Query latency (p95/p99) | Averages hide the slow queries users actually feel |
| Connections in use | Pool exhaustion fails every request at once, instantly |
| Slow query count | The early warning that an index is missing or a plan changed |
| Replication lag | Stale reads now, data loss if the primary dies |
| Lock waits / deadlocks | Contention that shows up as random app timeouts |
| Disk usage and growth rate | A database that fills its disk stops accepting writes |
| Cache hit ratio | Falling hit rates mean the working set outgrew memory |
Common Approaches#
- Engine-native views:
pg_stat_statements, MySQL's performance schema, slow-query logs. Free and precise; you assemble the dashboards and alerting yourself. - Agent-based monitoring: an agent on or beside the host ships engine metrics to a monitoring platform. The usual choice for self-managed databases.
- Managed-provider metrics: RDS, Cloud SQL, Supabase and similar expose metrics and alerts from their consoles; depth varies by provider and tier.
- Outside-in checks: scheduled requests against endpoints whose handler hits the database, asserting on response time and payload. This is the only approach that measures what users experience, and it works even when you cannot install anything.
These compose: engine views for diagnosis, provider or agent metrics for alerting, outside-in checks for ground truth.
Database Monitoring vs APM#
Application monitoring tells you which endpoint is slow and often which query it ran; database monitoring tells you why the engine made it slow (plan change, lock, saturated pool). One without the other leaves you with either a symptom or a cause you cannot tie to user impact.
Limitations#
- Metrics don't write indexes. Monitoring finds the slow query; fixing it is schema and query work.
- Internal metrics miss the user path. Replication can be healthy while the connection pool between app and database is exhausted; pair internal metrics with outside-in checks.
- Backups need their own proof. A green database tonight says nothing about whether last night's backup job ran. Scheduled jobs deserve their own monitoring (a heartbeat that the job pings on completion).
Best Practices#
- Alert on percentiles and trends, not averages; p99 latency and disk growth rate predict incidents.
- Set connection-pool alerts below the ceiling. At 100% it is already an outage.
- Watch replication lag with a hard threshold tied to how stale your reads are allowed to be.
- Prove the jobs ran. Backups, vacuums, and ETL get heartbeat checks, not assumptions.
- Keep a baseline. Most database incidents are "it changed"; knowing normal makes the change obvious.
Conclusion#
Database monitoring watches the engine your application leans on hardest: latency percentiles, connections, replication, and capacity, alerted on trends rather than averages. Internal metrics diagnose; outside-in checks confirm users are unaffected.
ObserveOne covers that outside-in half: API checks assert on the response time and JSON of endpoints backed by your database, and heartbeat checks catch the backup or ETL job that silently stopped running.