Database reliabilityBeginner
Monitor database replication and consumer lag
Which downstream database consumer is falling behind?
Compare replica, CDC, and search-consumer lag with explicit health classifications.
The dataset and query remain in this browser.
Published expected result
Maximum replication lag
warehouse_cdc
120 s
120 s
read_replica_us
18 s
18 s
search_index
10 s
10 s
| consumer_name | source_type | max_lag_seconds | average_lag_seconds | unhealthy_samples |
|---|---|---|---|---|
| warehouse_cdc | cdc_pipeline | 120 | 51.8 | 2 |
| read_replica_us | postgres_replica | 18 | 6.8 | 1 |
| search_index | search_replica | 10 | 6.3 | 0 |
How to read the query
- A shared consumer model makes operational replicas and asynchronous pipelines comparable.
- Maximum lag captures the worst user-visible staleness in the sample window.
- Health classifications can encode consumer-specific thresholds without hiding raw lag.
Decisions the SQL cannot make
- 1Prioritize consumers with both high lag and repeated unhealthy samples.
- 2Use backlog bytes to distinguish low-throughput staleness from sustained ingestion pressure.
- 3Set different service-level objectives for read replicas, CDC, and search indexes.
Continue from this lesson
Keep the result
Run this query on your own events
Create a free workspace only when you are ready to save the query, connect real events, and monitor the result. No credit card is required.