Slowly changing dimensions are how you store attributes that change over time without lying about history. Most teams need type 1 for corrections, type 2 for history you will analyse, and should reach for type 3 or hybrids only with a specific question in mind.
The decision is about questions, not elegance
A dimension is a noun you slice facts by: customer, product, employee, account. Some attributes are identifiers. Some are descriptive. Some change, and when they change you must decide whether old facts should move with them.
If leadership asks "what did this customer look like when they ordered," you need history. If they ask "what do they look like now," a current-state overwrite may be enough. Slowly changing dimensions are that decision, written into the table.
Type 0: attributes that must not change
Type 0 means the value is set once. Durable identifiers, original signup channel, original credit-risk band at account opening — if the business says these never update, the model should refuse the update.
Use type 0 sparingly. Calling everything type 0 is how you freeze bad data in place.
Type 1: overwrite, no history
Type 1 replaces the value. Use it for corrections (a misspelled name) and for attributes where history is noise (a support phone number).
Type 1 is also a trap. If you overwrite a sales region and then try to reproduce last quarter's regional report, the facts will follow the new region. That may be what finance wants. Confirm it in writing.
Type 2: a new row when the attribute changes
Type 2 keeps history by inserting a new version of the dimension member with effective dates, and closing the previous version. Facts key to the version that was true at event time.
This is the default for attributes that change and that you will analyse across time: customer segment, product category, account owner, billing plan.
It is not free. Type 2 grows the dimension, complicates joins, and needs a clear rule for what counts as a change. A trailing-space trim is not a new version. A move from "enterprise" to "mid-market" is.
Type 3: a little history in columns
Type 3 keeps "previous" and "current" on the same row. Use it only when the business asks for exactly one prior value, such as previous region, and will not later ask for the full timeline.
If they might ask for the full timeline, skip type 3 and do type 2. Column-based history does not extend cleanly.
Field notes on unifying data, governance and getting analytics teams to one source of truth.
Every Monday, five minutes.
Hybrids, including type 6
Type 6 typically combines a current-type-1 attribute on a type-2 row so you can filter facts either as-was or as-is. It is useful, and it is easy to implement wrong.
Only add a hybrid when you have both questions in production: "as it was at the time" and "as it is now, applied to history." If you only have one of those questions, stay with type 1 or type 2.
A practical chooser
For each attribute, ask four things: whether a change is a correction or a real world event, whether past facts must keep the old value, whether anyone needs more than the latest prior value, and whether the producer can even tell you when it changed.
If the producer cannot emit a change time, type 2 will be fiction. You can still snapshot daily, but that is a different design with different cost.
Put this chooser in the silver model, not in gold. Gold may select current or historical views. It should not be where you first invent history. That matches the spirit of Microsoft Fabric's 3 September 2026 medallion guidance: gold must not compensate for upstream quality, and silver is where the unified model lives.
Citi Global Wealth's silver-as-unified-data-model approach, reported by Computer Weekly on 8 September 2026, is the right layer for these rules. Once reporting is expected in days rather than weeks, quietly rewriting dimension history in a mart becomes a trust incident.
Implementation notes that save pain
Always have a durable business key plus a surrogate key. Type 2 versions share the business key and get new surrogates. Facts store the surrogate that was valid at event time.
Always have current-flag or end-date so current-state queries do not scan versions. Always decide what happens when a change arrives late: reopen the version, or treat it as type 1 on the current row and log an incident.
Do not type-2 every column. Identify the handful of attributes that change the meaning of a fact. The rest can type 1.
LensAIght, as a unified data intelligence platform, will happily chart whatever grain you model. It will not choose the SCD type for you. Wrong history in silver becomes confident nonsense in chat and in dashboards at the same time.
Frequently asked questions
Which slowly changing dimensions type do I actually need?
Most attributes need type 1 or type 2. Use type 2 when past facts must keep the old attribute. Use type 1 for corrections and for values where history does not matter.
Is type 2 always safer?
No. Type 2 without a real change timestamp creates fake history. It also bloats joins. Safer is matching the type to the question you can actually answer.
How do I handle a late correction to a type 2 attribute?
Decide in advance. Either issue a new version with a note that it is a correction, or patch the existing version. Mixing both without a rule will disagree with finance.
Can I change type later?
Yes, if bronze kept the source payloads. Rebuilding silver is why you did not clean in bronze. Changing type only in gold will drift.
Do I need type 3 if I already have type 2?
Almost never. Type 2 already contains previous values. Type 3 is a convenience for one prior value when you refused type 2.
Where should SCD logic run?
In the modelled (silver) layer, with tests on business keys, overlapping dates, and a single current row. Not in dashboard calculations.
Book a demo to see a managed data platform running on your own sources
LensAIght
