Snapshot Plus Delta

The pattern: store the full state at periodic snapshots plus the deltas between them. New reads can pick a snapshot and apply deltas to that point; old snapshots can be garbage-collected. Time-travel queries are trivial — “as of yesterday” is just “yesterday’s snapshot ID.”

The trade-off: storage cost vs. point-in-time access. Keeping many snapshots costs disk; expiring them loses time-travel. Most production systems pick a retention policy (7/30/90 days). Snapshot+delta is the engine behind Iceberg’s time-travel queries, ZFS rollback, and any storage system claiming “git-like” semantics for data.

Deepens in Year 3 Phase 15 — Iceberg’s metadata.json + manifests + snapshot retention is the worked example, running on basecamp’s lakehouse tier.

Related patterns

• append-only-log — the delta stream is itself an append-only log.
• write-ahead-logging — same idea applied to durability instead of time-travel.
• schema-on-read-vs-write — snapshots are what make schema evolution reversible.
• materialized-views — incremental refresh is snapshot+delta in disguise.