Why Snapshots Alone Don’t Give You True History

Snapshots Feel Simple — But Hide a Problem

When a source system delivers a daily or monthly snapshot, it feels natural to just store it. Every delivery is a photo of the dataset at that point in time.

At first, this looks like the easiest strategy:

Simple to implement → just INSERT the new file every day.

Familiar to consume → many reports are also snapshot-based (month-end balances, reporting date views).

But this approach hides two major issues: storage bloat and loss of true history.

The Storage Problem

Snapshots duplicate data.

Imagine a customer’s address that doesn’t change for three years. With snapshots:

• That same address row is copied into every delivery.
• Over time, you store thousands of identical rows.

Storage grows linearly with every delivery — even when nothing changes.

The History Problem

Snapshots tell you what data looked like on a date, but not from when to when it was valid.

Example:

• You see that a party’s marital status was “Single” on April 30.
• You see that it was “Married” on May 1.

But you don’t know exactly when the change occurred — only that it happened between the two snapshots.

To reconstruct the functional history (“valid from April 27 until April 30”), you have to diff snapshots and infer the timeline. This is compute-heavy and often ambiguous.

Why Functional History Matters

In a business logical data model (LDM):

• Core entities like Party or Account are stable.
• Characteristic and associative entities (like Party_Address or Party_Marital_Status) explicitly carry a validity timeline with valid_from and valid_to.

This matches how source applications actually track changes — e.g., an address is valid from a specific date until it changes.

If your integration layer only stores snapshots, you lose this clarity. Consumers who need history — for compliance, investigations, or data science — face a painful reconstruction exercise.

The SCD2 Alternative

Slowly Changing Dimension Type 2 (SCD2) solves this by storing changes with explicit validity periods:

• Each new version of a record gets a new row with valid_from / valid_to.
• If nothing changes, no new row is added.

The result:

• Efficient storage → no duplicates, only changes.
• Transparent history → you always know when a value was valid.
• Easier queries → no need to diff snapshots to find timelines.

Snapshots Still Have a Place

Snapshots aren’t bad — they’re just not enough.

They remain the best format for:

• Receiving inbound data from sources (IDS deliveries).
• Delivering outbound data to consumers who want a reporting-date view.

The trick is to separate the integration model from the delivery model:

• Integration layer → store data in SCD2 form (historized, LDM-aligned).
• Delivery layer → expose snapshot views (via PIT tables), historized views, or dimensional models depending on the consumer’s need.

The Balanced Approach

• Snapshots are great for delivery.
• SCD2 is essential for integration.
• PIT tables bridge the gap — making snapshot views fast, while keeping history explicit in the core model.

This layered approach gives you the best of both worlds:

• True historical clarity when you need it.
• Snapshot convenience when you want it.
• Lower storage, lower compute, higher confidence in your data.

👉 In short:
Snapshots are simple, but they don’t give you true history.
SCD2 does — and with PIT tables, you can still serve snapshots efficiently.