Slowly Changing Dimensions (SCDs) are how data systems manage attributes that evolve without constantly rewriting history. They determine whether you keep only the latest value, preserve full historical versions, or maintain a limited snapshot of changes. The classic SCD types (0–3, plus hybrids) define different behaviours… from never updating values, to overwriting them, to keeping every version with timestamps. The real purpose of SCDs is to make an explicit choice about how truth should behave in your analytics: what should remain fixed, what should update, and what historical context matters. Modern data platforms make tracking changes easy, but they don’t make the design decisions for you. SCDs are ultimately the backbone of reliable, temporal, reality-preserving analytics.

Contents

Introduction

If you’ve ever stared at a data warehouse schema and muttered, “What the fuck is SCD?”, you’re not alone. The term sounds like something invented to intimidate newcomers. But under the jargon sits one of the most quietly important concepts in analytics and data engineering: Slowly Changing Dimensions. This article kicks off two things for me: a new “WTF is…” explainer series and a practical mini-series on building Financial Services–grade data platforms using SCD2 at the Bronze layer. Let’s break it down in a way that’s actually helpful and hopefully clever enough to feel like time well spent.

So… What Is a Slowly Changing Dimension?

A dimension is just a descriptive table: people, products, locations, organisations—things that have attributes.
A slowly changing dimension is one where those attributes… well… change. But not every five minutes. Slowly. In human time.
If the attribute changes constantly, daily or even hourly, that’s a Fast-Changing Dimension, which is a different modelling challenge entirely. This article focuses on the slower, business-meaningful changes.

Example:

• People move house
• Products get rebranded
• Departments merge
• Someone decides “Head of Emerging Strategy” is now “Strategy Innovator” because LinkedIn said so

These changes matter. Because analytics depends heavily on historical truth. If your data model can’t track how a dimension evolved, you end up rewriting history—and not in a heroic “rewrite the timeline to save the universe” way. More like: “Wait… why do last year’s sales reports think all our customers live at their new addresses?”

Why Should You Care?

Because if you’re doing analytics, building a modern data platform, or even just trying to avoid looking foolish in front of a BI team, you must understand how you want history to behave.

Do you want:

• The latest value only?
• The historical value as it was at that time?
• A full genealogy of how each attribute changed over its lifetime?

Different use cases require different answers. That’s why SCDs exist. And why we can’t just pick one behaviour for all data, unless we enjoy self-inflicted chaos.

In most modern data stacks, SCD2 sits at the modelling layer, often in the Medallion Silver layer or the semantic layer, where you need both historical reconstruction and a clean ‘current’ view for BI. Increasingly for Financial Services or highly regulated businesses hosting SCD at a foundational level, tracking all changes, and delivering operational and analaytic “views” over it make more sense.

The Types (a.k.a. The Necessary Evil)

The industry insists on categorising SCDs, and honestly, the classic five types are still the most useful mental model.

SCD Type 0 – The Stone Tablet aka “Retain Original”

• You never update the attribute.
• History is sacred.
• Example: date of birth.
  If this changes, you have a different problem entirely.

SCD Type 1 – The “Overwrite It and Move On” aka “Overwrite”

• No historical tracking.
• Just replace the old value with the new one.
  Useful for correcting mistakes (typos, formatting errors, etc.).

SCD Type 2 – The Historian’s Delight aka “Add New Row”

• You keep every version, with start/end dates.
• Perfect for anything where you care how the attribute changed over time.
  This is where most real analytic value sits.

SCD Type 3 – The Halfway House aka “Add New Attribute”

• Keep the current value and the previous one.
• Rare, but occasionally useful when only one historical step matters.
  • An example is tracking a customer’s current and previous sales region when compliance or reporting rules require both. Another is keeping the previous product name after a minor rebrand.

SCD Type 4, 5, 6, and 7

Types 4–7 mostly live in the archives: dusty corners of Kimball books and ageing enterprise warehouses. Modern tooling blurs these distinctions, but it’s still worth knowing what problems they were originally trying to solve.

Pro tip: In the real world, almost everything important ends up Type 2.

• SCD Type 4 – “Add History Table”
  • Keep the current record in the main table; store changes in a separate history table.
• SCD Type 5 – “Type 4 + Type 1” (Current profile + history)
  • Useful when you want fast access to the current view and separate long-term history.
• Type 6 – “1 + 2 + 3 Combined”
  • Type 6 is a hybrid approach combining Type 1, Type 2, and Type 3 behaviours. It stores a Type 2 row, adds a Type 3 attribute for the previous value, and still applies a Type 1-style overwrite to the current view.
  • There are two common sub-variants:
    • Type 2 surrogate key with type 3 attribute
    • Pure type 6 implementation
  • If this sounds like overkill, that’s because it usually is.
• Type 7 – “Surrogate + Natural Key Hybrid”
  • Mostly seen in legacy warehouse patterns, modern modelling patterns rarely require it.

The Real Question: How Do You Want History to Behave?

SCDs are ultimately about intentionality.
The worst architectures don’t fail because someone chose the wrong option, they fail because nobody chose anything. As the old line goes: bad things triumph when good teams do nothing.

Ask yourself:

• Does the past matter for this attribute?
• How expensive is it to store historical versions?
• How expensive is it to not store them?
• Will your analysts ever need to recreate past states?
• And the big one:
  What does the business actually think “truth” means?

Often, “truth” is contextual.
Analytics is about making that context explicit.

Modern Platforms Make SCDs Easier… and Harder

Tools like dbt, Snowflake, BigQuery, and Lakehouse engines offer powerful mechanisms for versioning, snapshotting, and tracking history. That’s great.

But here’s the catch:

• Because it’s easy to record everything, people sometimes track far more history than they need.
• Because it’s easy to ignore the decision, teams sometimes never make one.

Slowly Changing Dimensions are still a design choice.
The tools won’t think for you.

So, What the Fuck Is SCD?

It’s the backbone of historical truth in your data systems.
It’s how you stop your dashboards rewriting reality.
It’s how you ensure that when the business asks, “What happened back then?”, you have something more sophisticated than a shrug.

In short:

A Slowly Changing Dimension is the discipline of deciding how your data evolves through time, and having the technical backbone to support that decision.

Once you understand that, the jargon stops being a barrier and becomes a means of communicating clarity.

This is the first in the ‘WTF is…’ series, where I break down foundational concepts without the usual jargon or reverence. More instalments coming.

And with that, you never have to ask WTF SCD is again.