Branch out your SQLite Database with LiteTree

Whether you want some quick and dirty data storage, or simply don’t have that heavy requirements for your local database system, SQLite is always a good choice. With its portable single-file approach, bindings to all major languages, and availability on systems of all sizes, it is relatively easy to integrate a SQLite database in your undertakings. And if you tend to develop directly in your production environment, you may be interested to hear that the folks at [aergo] made this a lot more flexible (and interesting) by adding Git-style branching to the SQLite engine.

Similar to Git, each database operation is now stored as a commit with a unique id as reference point, and new branches will keep track how they diverge from their parent reference point. This essentially lets you modify your data set or database schema on the fly, while keeping your original data not only untouched, but fully isolated and functional. Unfortunately, merging branches is not yet supported, but it is planned for the near future.

In case you don’t see much use for git-alike functionality in a database, how about the other way around then: using Git as a database, among other tricks?

5 thoughts on “Branch out your SQLite Database with LiteTree

  1. I got excited when I saw the heading, then disappointed with the details.
    I’ve been wanting for years – and have never managed to have the time to write it myself – for someone to bring out a hierarchical database equivalent of SQLight.. Not every problem in the world is best done with a relational database – something most of the world seems to have forgotten – and I dream of an open source (much smaller) equivalent to IMS DB.. :-)

  2. SQLLite uses MVCC, so it basically already stores commits as branches with unique IDs. This doesn’t really seem to be building on that, though. It looks like they are instead working at the page level.

    They are using the LMDB key value store (which also uses MVCC) as the SQLlite storage engine and, I guess, doing the versioning/snapshotting there. Maybe analogous to the difference between a filesystem with copy on write support, and an ordinary journaled filesystem running on top of a logical volume manager with snapshot support. The author of LMDB also

    At least that’s the best I can do given my superficial understanding of DBMS architecture. It passes the test of not being yet another DADBMS (dumbass database management system) in that the author chose to build on two mature, well designed codebases. So, that’s good.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.