All stacks · Quality & modeling
Star schemas, SCDs, Data Vault, and warehouse design.
Data ModelingWorking SQL for every SCD type, the point-in-time join that most Type 2 implementations get wrong, and an honest account of which types are worth the maintenance.
Data ModelingJoins are not the expense they were in 2015. Here is what a wide denormalized table really costs in storage, rebuild time, and history, and the hybrid I ship instead of picking a side.
Data modeling is the most durable skill in the field: engines and vendors rotate every five years, but grain, keys, facts, and dimensions have outlived four decades of tooling. Every incident where two dashboards disagree traces back to a modeling decision someone skipped.
These articles teach modeling as production practice — declaring grain before writing SQL, star schemas that BI tools consume without gymnastics, SCD implementations that survive backfills, and when Data Vault or One Big Table genuinely fits instead of following fashion.
More than ever. Cheap compute made denormalization affordable, but BI tools, semantic layers, and human comprehension still work best against facts and dimensions at a declared grain. The medallion pattern is dimensional modeling's gold layer wearing new clothes.
What one row represents: "one row per order line per day" is a grain. Every fact table needs its grain stated in one sentence before any SQL is written — nearly every double-counting bug is a grain violation caught too late.
Type 2 (new row per change with valid_from/valid_to) for anything analytical questions care about historically — customer segments, product prices. Type 1 (overwrite) for corrections. dbt snapshots give you Type 2 with a config block.
Large organizations with many volatile sources, strict audit requirements, and dedicated modeling teams. Its insert-only hub/link/satellite structure absorbs source change beautifully but roughly triples object count — for most mid-size teams, staging plus star schemas wins.
Pragmatic at the serving edge: a wide, denormalized table feeding one dashboard or ML feature set is fine. Lazy as a foundation: without conformed dimensions underneath, every new OBT re-derives logic and the disagreements begin.
One email a week with our latest tutorials. No spam.
Newsletter signup is not live yet. Use the contact form if you want to be notified.