DATA ARCHITECTUREHistory

Slowly Changing Dimensions (SCD 0–7)

How data engineers design data that lasts — pick a topic on the left and its full breakdown loads here: the mental model, ERDs and worked schemas, trade-offs, edge cases, and the decisions that separate a durable model from a fragile one.

18 min readTopics chapter readerLevel · Dimensional & Warehouse
01 · Orientation

What You'll Master Here

overwrite (lose history), add a row (keep full history), or add a column (keep limited history).

4 min · Topic 1 of 12

Dimensions describe the world, and the world changes: a customer moves state, a store is re-districted, a subscriber switches tariff. Slowly changing dimensions (SCDs) are the named strategies for one question — when an attribute changes, what happens to history?

Apply each type to the same move below and watch two things move with it: the rows in dim_customer, and the answer to a Q1 question that has only one true answer. The selector opens on Type 1, the one you get by accident.

Core mental model

When a dimension attribute changes, you choose: overwrite (lose history), add a row (keep full history), or add a column (keep limited history).

Why it matters

Whether history is preserved decides if you can ever answer "what was true then?". Choosing the wrong SCD type means either losing history forever or bloating dimensions needlessly, and it is very expensive to change after data accumulates.

slowly changing dimension
A dimension whose attributes change over time, requiring a history strategy.
Type 1
Overwrite the attribute; no history is kept.
Type 2
Add a new row with effective dates; full history is preserved.
effective dating
valid_from / valid_to columns that mark when a row's values were true.
One customer, one move, six different answersCustomer C-7 bought twice in Q1 while living in NY, then moved to CA on 1 June 2026.
Type 1 · overwrite in place1 row
dim_customer after the move
customer_keycustomer_idstate
501C-7CA
fact_sales — unchanged by any of this
sale_idcustomer_idsale_dateamount
s1C-72026-02-1440.00
s2C-72026-03-1025.00
s3C-72026-07-0260.00
The question the business asks

“What were Q1 2026 sales by state?”

The two Q1 sales total 65.00 and were both earned while C-7 lived in New York. Any answer other than NY 65.00 is wrong.What the report returns
stateq1_revenue
CA65.00
  • Q1 as it was · wrong, and silently so
  • Where C-7 lives now · answered correctly
Q1 revenue moved to a state it was never earned inOne UPDATE replaced NY with CA, and because there is now no record that NY ever existed, both Q1 sales re-attribute to California. Nothing errored. The Q1 report that was published in April now returns a different answer, and the row that would have proved it wrong has been overwritten.
Common mistake

Overwriting dimension attributes everywhere by default. History is destroyed: past facts silently re-attribute to current attribute values, corrupting trends.

Better habit

Decide a history strategy per attribute, not per table.

Default important descriptive attributes to Type 2.

Always store the surrogate key on facts so history is queryable.

Why this one comes up so often

SCD is the most asked dimensional-modeling interview topic because it is the cheapest way to tell whether a candidate has ever had to defend a historical number. The follow-up is always the same: which type, and for which attribute?

Remember this

SCDs decide what happens to history when a dimension attribute changes; the choice (overwrite, add row, add column) determines whether you can ever report the past accurately.