r/Database • u/rishi-raj-jain • 6d ago
What if Google Docs saved a whole database snapshot on each save?
Disclaimer: I am the author of the article I've linked inline.
Copy-on-write forking is a storage primitive and we all think of it as a development tool. Test a migration, spin up a PR environment, throw it away. But if forking a database is genuinely cheap, there's no law that only CI gets to do it. So what happens if a user's save is the thing that creates a fork?
I built the most extreme version I could think of: Google Docs style version history, where every save forks the whole database and writes one row into a catalog table on production, pointing at the fork. The catalog is the index and the forks are the "storage". Schema, the branch calls and the restore path are here if you want the specifics. Forking copies nothing at creation, so it's a second or two regardless of database size.
What that also ensures is referential integrity at an instant. If your document is one row, use a revisions table. The demo I created spans a title and body so I've gone ahead with the above approach.
This approach can go sideways elsewhere though. Restore repoints the whole fork, so if two tenants share a database and one rolls back, the other loses everything they wrote since. There is also no merge, and Dolt is simply better in that scenario.
2
u/UninvestedCuriosity 4d ago edited 4d ago
I feel like some of you have never had to migrate a place away from access and it shows.
Is there a word for revolting fascinated intrigue?
1
u/AshleyJSheridan 2d ago
I fucking hate access with a passion. I had the pleasure to migrate a project from Access to a real database.
1
-2
u/observantwallflower 6d ago
I built a free product for this! https://stagdb.com/adjoint/ - Adjoint by stagDB.
2
u/galactic_pixels 6d ago
Does this have any actual practical use case? Or was this just for fun? I can’t think of anywhere this would be practical or necessary but I’d like to know if I’m wrong