A semi-common feature that many SaaS products have the ability to store and restore older versions of a "document", e.g. Google Docs, Notion, Figma. However, most of these products feel like they have a document rather than db-based model that operates on multiple tables. For example Figma has a great article about how their documents are actually files rather than database rows: https://digest.browsertech.com/archive/browsertech-digest-figma-is-a-file-editor/<p>So for a system that is built on top of multiple database tables to load a single page/document how would you go about creating and storing a version history for all the related tables? Or would you use a non-db approach somehow?
(oh hey, author of that article here :))<p>This is something I've been thinking a lot about as well. A cool approach I've been experimenting with is using a CRDT for the underlying document data, and taking snapshots of the logical clock that correspond to version numbers. If you don't garbage-collect the CRDT, you can then restore the value based on the logical clock.<p>The CRDT itself can be persisted to S3 or similar, as in that article. We’ve been working on this in the open, so you can follow along: <a href="https://y-sweet.dev/" rel="nofollow noreferrer">https://y-sweet.dev/</a>
If you just need to restore older versions of a (non-text) doc and don't need to support things like diff and merge, a handy approach is to store all the steps needed to create the doc, same as you would to implement undo/redo and allow "tagging" the operation stream to create your versions.<p>There are a lot of ways to optimize this sort of thing in practice so it runs reasonably, but that's an exercise for the implementer.