[kpmah]

Author here, 8 years on.

Although the advantages are real, I can't say I have had much opportunity to implement schemas like this. The extra complexity is usually what gets in the way, and it can add difficulty to migrations.

I think it would be useful in certain scenarios, for specific parts of an application. Usually where the history is relevant to the user. I think using it more generally could be helped by some theoretical tooling for common patterns and data migrations.

[lichtenberger]

You can use Datomic for instance (mentioned already in your article IIRC!?) or SirixDB[1] on sich I'm working in my spare time.

The idea is an indexed append-only log-structure and to use a functional tree structure (sharing unchanged nodes between revisions) plus a novel algorithm to balance incremental and full dumps of database pages using a sliding window instead.

[1] https://sirix.io | https://github.com/sirixdb/sirix

[benjaminwootton]

I agree this is more of an application level concern than a database thing. If you need to maintain a history for the user requirement then you will naturally land on a scheme like this.

We also have help from other quarters nowadays.

Databases often provide a time travel feature where we can query AS OF a certain date.

Some people went down the whole event sourcing / CQRS / Kafka route where there is an immutable audit log of updates.

Data warehousing has moved on such that we can implement “slowly changing data” there.

All in all, complicating our application logic, migrations and GDPR in order to maintain history in line of business applications might not be worthwhile.

[refset]

> Databases often provide a time travel feature where we can query AS OF a certain date.

This is a good overview of SQL:2011 temporal functionality support across the major players: https://illuminatedcomputing.com/posts/2019/08/sql2011-surve...