Comparisons
Snapshots vs bitemporal history
Snapshots preserve states at selected moments; bitemporal history distinguishes when a fact applied from when it was recorded.
The distinction
A snapshot preserves the state of a dataset at a chosen point. It can support reporting, backup, comparison, and reproducible analysis when the snapshot is complete and its creation time is known. Snapshots are simple to reason about, but intervals between them can conceal changes. A snapshot taken today may also contain a correction about last month without showing when the organization first learned of the corrected fact. Retaining more snapshots reduces gaps but does not by itself explain effective dates.
Bitemporal history separates valid time, when a fact applies in the modeled world, from transaction time, when the system recorded that fact. This distinction permits questions such as what was believed on a past day about a period even further in the past. It matters when late-arriving evidence, retroactive corrections, or audit review are routine. The model adds query and governance complexity: users must state which time axis they mean, and a dated record still needs source evidence to justify a correction.
By dimension
| Dimension | Snapshots | Bitemporal history |
|---|---|---|
| Time represented | The state captured at each snapshot date. | Both effective time and recorded time. |
| Between captures | Intermediate changes may be absent. | Changes can be retained as dated intervals or events. |
| Late correction | A later snapshot shows the new state. | The correction can show both its effective and recording dates. |
| Typical query | What did this captured dataset contain? | What applied then, and what did we know then? |
| Operational burden | Storage and retention policy for whole copies. | Careful handling of temporal semantics and revisions. |
| Reproducibility | Strong at retained capture points. | Strong across specified time axes when history is complete. |
| Common error | Treating the capture date as the fact's effective date. | Confusing valid time with transaction time. |
Choose Snapshots when
- Periodic reporting needs fixed, retained datasets.
- Changes between captures are immaterial to the use case.
- Simple restoration or comparison is the goal.
Choose Bitemporal history when
- Corrections can apply retroactively.
- A decision must be reconstructed as it appeared to users at the time.
- Valid and recorded dates have different legal or operational meanings.
Using both
Use snapshots as stable analysis artifacts derived from a bitemporal record, with the query dates and snapshot creation time recorded.
A worked example
A fictional regulator publishes a weekly file of authorized medicinal products. A weekly snapshot of that file is easy to keep. On 10 March a product is shown as authorized. On 17 March the file shows it as suspended, with a note that the suspension took effect on 1 March and was entered late.
A question arrives: was the product authorized on 5 March? The snapshot of 10 March says yes, and it was what everyone saw. The snapshot of 17 March says no, because the suspension was effective on 1 March. A bitemporal record holds both facts: the product was suspended from 1 March, valid time, and the system learned of it on 17 March, transaction time. It can answer the question in two ways, as the world was and as it was then believed, and it keeps the two answers apart.
Where each one fails
Snapshots fail between captures and at corrections. Anything that changed and changed back between two snapshots is invisible. A correction applied to a later snapshot does not show what had been believed earlier unless the earlier snapshot is kept, and nothing in a snapshot records when a fact took effect.
Bitemporal histories fail through complexity and discipline. Queries must state which time axis they use, and users routinely confuse them. Corrections must be entered as new rows with proper intervals, not as edits, or the history is lost. Writers need to supply valid times, which sources do not always state. The SQL standard added support for such tables in 2011, and practitioners describe common pitfalls in using them.
Questions to settle before choosing
How often do corrections arrive late, and do they apply retroactively? Does a reviewer ever ask what was believed on a past date? Are decisions defended against the information available at the time? How long must history be kept? What is the cost of a wrong answer to a replay question? If retroactive correction is rare and replay questions never arise, snapshots with good retention may be enough. If either occurs regularly, snapshots will eventually give the wrong answer with great confidence.
How the two meet in a review
Snapshots remain useful as derived artefacts: a fixed extract for a report, a backup, a dataset handed to a third party. The recommendation is to derive them from the bitemporal store with the query dates recorded, so that the snapshot can be explained and, if necessary, recreated. A snapshot with a stated as-of date and recording date is a view of a history, not a substitute for it.
See also
- Data warehouse vs system of record
- Reproducing a past state
- ISO 8601 date and time representation
- Valid time
- Transaction time
- As-of query
Further reading in the articles
Found an error on this page? See corrections for what counts as one, how to report it and the dated log.
Enquiry
Which do you run today: Snapshots or Bitemporal history?
Describe how your organization handles this now and one entity where it falls short. We reply with where a first record would sit alongside it and what it would need from you.
Or write to [email protected] in your own words.