Why row count alone won't catch most data incidents
Row count is the first metric everyone tracks and the last one that catches a real problem. Null rates, duplicate keys, and freshness tell a more complete story.
The Relium blog
SQL patterns, dbt operations, incident management, and the hard-won lessons from running analytics in production.
-- before: this looks fine
SELECT c.id, COUNT(o.id) AS orders
FROM customers c
LEFT JOIN orders o ON c.id = o.customer_id
WHERE o.status = 'completed'
-- after: what you meant
LEFT JOIN orders o
ON c.id = o.customer_id
AND o.status = 'completed'
Featured · SQL patterns
A single WHERE clause in the wrong place turns a LEFT JOIN into an inner join. Your pipeline passes. Your active-customer count is wrong. Here's how to catch it before it ships.
Recent posts
Row count is the first metric everyone tracks and the last one that catches a real problem. Null rates, duplicate keys, and freshness tell a more complete story.
When raw_orders drops rows, every downstream model fires separately. Correlation groups them into a single incident with one root cause and one clear action.
The manifest.json is the most underused file in a dbt project. Here's how to extract lineage, ownership, and risk exposure from it without touching the warehouse.
A model that feeds a metric that feeds a dashboard that feeds a board report has a blast radius of four. Most teams don't know the number until something breaks.
SELECT *, hardcoded date filters, COALESCE(x, 0) in aggregations — each one is a time bomb that passes CI and fails silently in production.
When a table's latest row is 48 hours old, that's not a data quality signal. That's a broken promise to every dashboard downstream. Here's how to model it properly.
Earlier
Root cause reports get ignored when they're written for engineers. A good RCA has a one-line summary, evidence, impact, and a clear next action — nothing else.
Most data teams run dbt compile in CI. That catches syntax errors. It doesn't catch a join that removes 30% of your customer base. Here's what a real data CI check looks like.
You can detect nearly every meaningful data quality problem without scanning raw records. Row counts, null rates, freshness, schema drift — metadata tells the story.
No posts match that topic yet.