Database Monitoring: Key Metrics to Track

If you are setting up database monitoring, the hard part is not collecting metrics, it is knowing which ones predict trouble. Dozens of counters are available; only a handful tell you an incident is coming. This is the shortlist, grouped by what they measure, with what each one is, why it matters, and the rough sign that something is wrong.

One ground rule before the list: the exact numbers vary by engine. Postgres, MySQL, and others expose different counters and define "healthy" differently, so the trouble signs below are framed as movement off your own baseline rather than fixed thresholds. Knowing what normal looks like for your database is what makes a bad reading obvious.

Throughput and latency#

This group answers "is the database fast, and for whom."

• Queries per second (QPS). The volume of statements the engine is handling. It matters as context: a latency spike means one thing under steady load and something else when traffic just doubled. Trouble sign: a sudden drop (the app stopped sending work, often because something upstream is stuck) or a sustained climb past what your hardware was sized for.
• Query latency (p95/p99). How long statements take, measured at percentiles rather than averages. It matters because the average is dominated by fast queries while users feel the slow tail. Trouble sign: p99 rising while p50 stays flat, which means a subset of queries degraded even though the typical one looks fine.
• Slow query count. The number of statements crossing a "too slow" line you define. It matters as an early warning that an index is missing, the data grew, or a query plan changed. Trouble sign: the count stepping up after a deploy or a schema change, usually pointing at one new or altered query.

Connections#

• Active vs idle connections. How many connections are running a query versus sitting open and unused. It matters because connections are a bounded resource and idle ones still occupy a slot. Trouble sign: idle connections piling up (a pool that opens but does not reuse) or active connections staying high, which means queries are not finishing fast enough to free their slots.
• Connection pool saturation. How close the pool is to its configured maximum. It matters more than almost any single metric: when the pool hits its ceiling, new requests wait or fail all at once, so a saturated pool turns into an outage instantly. Trouble sign: utilization trending toward the max. By the time it reads 100% you are already shedding requests, so alert well below the ceiling.

Replication#

• Replication lag. How far behind a replica is from the primary, measured in time or in unapplied changes. It matters on two fronts: reads served from a lagging replica are stale, and if the primary fails before the replica catches up, the gap is data loss. Trouble sign: lag trending upward instead of hovering near its baseline, which means the replica cannot keep pace with the write rate. What counts as acceptable depends on how stale your reads are allowed to be.

Cache#

• Cache / buffer hit ratio. The share of reads served from memory instead of disk. It matters because memory reads are orders of magnitude faster, so a high ratio is what keeps latency low. Trouble sign: the ratio falling from its usual level, which usually means the working set has outgrown available memory and the engine is going to disk more often. The exact counter and what "normal" looks like differ by engine, so watch the trend against your baseline.

Resources#

The host metrics underneath the engine. These overlap with server monitoring, but for a database they are read as capacity signals.

• CPU. Processing headroom. High CPU often means expensive queries or missing indexes forcing full scans. Trouble sign: sustained saturation rather than brief spikes.
• Memory. RAM available for the cache and working operations. Pressure here shows up first as a falling cache hit ratio and more disk activity. Trouble sign: steadily shrinking free memory or rising swap.
• Disk space. Free storage. It matters bluntly: a database that fills its disk stops accepting writes. Trouble sign: the growth rate, not the current number; a steady climb tells you when you will run out.
• Disk IOPS and latency. The rate and speed of disk operations. It matters because once the working set spills out of memory, disk speed becomes the ceiling on query speed. Trouble sign: IOPS pinned at the volume's provisioned limit, or disk read latency climbing.

Locks and contention#

• Lock waits. Time queries spend blocked waiting for another transaction to release a lock. It matters because contention surfaces in the app as random, hard-to-reproduce timeouts that the query itself looks fine for. Trouble sign: wait time rising under concurrency, often around a hot row or table.
• Deadlocks. Two or more transactions each holding what the other needs, which the engine breaks by killing one. It matters because the victim's work is rolled back and the app sees an error. Trouble sign: a deadlock count that is anything but flat near zero, which points at a transaction-ordering problem in the code.

Errors#

• Database error rate. Failed statements and rejected connections: timeouts, constraint violations, permission failures, and refusals when limits are hit. It matters as the most direct signal that users are being turned away right now. Trouble sign: any rise off baseline, with the error type pointing at the cause (connection refusals point at the pool or limits, timeouts at slow queries or locks).

Where to start#

You do not need all of these on day one. If you are starting from nothing, four metrics catch most real incidents:

1. Query latency at p95/p99, because it is the closest internal proxy for what users feel.
2. Connection pool saturation, because it is the failure that takes everything down at once.
3. Disk space and growth rate, because running out stops writes cold and is entirely preventable.
4. Replication lag if you serve reads from replicas or rely on them for failover.

Add slow query count, cache hit ratio, locks, and the resource metrics as you learn where your database actually hurts. Alert on percentiles and trends, not averages.

Conclusion#

These metrics live inside the engine, so collecting them means an agent, the engine's own views, or your managed provider's console. That tells you the database is healthy. It does not tell you the user is unaffected, and the two come apart more often than you would expect: replication can look fine while the pool between the app and the database is exhausted.

ObserveOne covers that outside-in half. Scheduled API checks hit the endpoints backed by your database and assert on response time and payload, so you measure the user-facing impact of whatever the internal metrics are showing, and heartbeat checks catch the backup or batch job that quietly stopped running. Pair the internal metrics with checks from the outside and you see both the cause and whether anyone is actually feeling it.