What Key Metrics Should You Monitor for a Database?
Learn the key database metrics — latency, throughput, replication lag, and cache hit ratio — every engineer should monitor.
Expected Interview Answer
The core database metrics to monitor are query latency and throughput, connection pool saturation, replication lag, cache hit ratio, disk I/O and space usage, and lock or wait-event contention, because together they reveal both current health and looming capacity problems.
Latency percentiles (p50/p95/p99) and queries-per-second show whether the workload is being served fast enough, while connection counts against the configured max reveal saturation before clients start getting rejected. Replication lag matters because a lagging replica can silently serve stale reads or fail over with data loss. Buffer/cache hit ratio indicates whether the working set fits in memory, and disk I/O plus free space warn about hardware bottlenecks before they cause outages. Lock waits and long-running transactions expose contention that raw throughput numbers hide.
- Surfaces performance regressions before users complain
- Gives early warning of capacity limits
- Distinguishes application bugs from infrastructure limits
- Feeds alerting thresholds and on-call runbooks
AI Mentor Explanation
A team analyst does not wait until a series is lost to check form; they track a batter's strike rate, a bowler's economy, and fielding error counts every single match. A sudden dip in strike rate or a rising economy rate flags a problem long before the team loses a match outright. Database monitoring works the same way: latency, throughput, and error-rate dashboards are the strike rate and economy of the system, catching decline before an outage becomes visible to users.
Step-by-Step Explanation
Step 1
Instrument core metrics
Collect query latency percentiles, throughput, connection counts, replication lag, cache hit ratio, and disk I/O from the database and OS.
Step 2
Set baselines
Establish normal ranges for each metric under typical load so deviations are detectable.
Step 3
Configure alert thresholds
Alert on saturation (e.g. connections near max), rising p95/p99 latency, and growing replication lag before they cause errors.
Step 4
Correlate and act
Cross-reference spikes with deploys, slow queries, or lock contention to find root cause and remediate.
What Interviewer Expects
- Naming latency, throughput, and connection saturation as core metrics
- Mentioning replication lag and cache hit ratio, not just CPU/RAM
- Awareness of percentile-based latency over averages
- Connecting metrics to actionable alerting, not just dashboards
Common Mistakes
- Only mentioning CPU and memory, ignoring database-specific metrics
- Using averages instead of percentiles for latency
- Not mentioning replication lag as a distinct, critical metric
- Treating monitoring as dashboards only, with no alerting strategy
Best Answer (HR Friendly)
“I would monitor query latency at the p95/p99 level, throughput, how full the connection pool is, replication lag, cache hit ratio, and disk space and I/O. These together tell you whether the database is healthy right now and whether it is heading toward a capacity problem, so you can act before users are affected.”
Code Example
-- Active connections vs configured max
SELECT count(*) AS active_connections
FROM pg_stat_activity;
-- Cache hit ratio (should stay close to 0.99)
SELECT
sum(heap_blks_hit) / nullif(sum(heap_blks_hit) + sum(heap_blks_read), 0) AS cache_hit_ratio
FROM pg_statio_user_tables;
-- Replication lag in seconds on a replica
SELECT
extract(epoch FROM now() - pg_last_xact_replay_timestamp()) AS lag_seconds;
-- Long-running queries and blocked locks
SELECT pid, state, wait_event_type, now() - query_start AS duration, query
FROM pg_stat_activity
WHERE state != 'idle'
ORDER BY duration DESC
LIMIT 10;Follow-up Questions
- How would you set alert thresholds without causing alert fatigue?
- What is the difference between average latency and p99 latency, and why does it matter?
- How do you monitor a sharded or multi-region database differently?
- What tools would you use to collect and visualize these metrics?
MCQ Practice
1. Why are latency percentiles (p95/p99) preferred over averages for database monitoring?
An average can look healthy while a significant fraction of requests are slow; percentiles expose that tail behavior.
2. Why is replication lag an important metric to monitor?
High replication lag means reads from a replica can be stale, and failing over to it can drop the most recent committed writes.
3. A consistently low buffer/cache hit ratio most directly suggests what?
A low cache hit ratio means the database frequently reads from disk instead of memory, often because the working set exceeds available cache.
Flash Cards
Name three core database metrics to monitor. — Query latency (percentiles), throughput, and connection pool saturation, among others like replication lag and cache hit ratio.
Why use p95/p99 instead of average latency? — Averages mask tail latency; percentiles reveal how slow the worst-affected requests actually are.
What does replication lag measure? — The delay between a write committing on the primary and it being applied on a replica.
Why track cache hit ratio? — It shows whether the working set fits in memory or the database is frequently hitting slower disk reads.