Dolt is pitched as Git but for data, or a versioned MYSQL.
Since Xtdb also focuses on SQL versioning, or bitemporality, I was wondering how they compared.
I guess Dolt has special features like rollbacks and merging of databases, whereas Xtdb more generally lets you query data across time.
Since you guys have more experience with these terms and nuances I figured a comparison was worth asking about. Thanks.
Hey @ac1 - great question - thereās definitely a decent amount of overlap in vision between the projects 
Did you read So you want a Temporal Database? by the Dolt team already? Itās pretty good! It doesnāt reflect what weāre doing currently with XTDB v2 (full SQL support, cross-time querying, Apache Arrow etc.), but is broadly accurate.
My main area of disagreement is around this statement:
Note, valid time and decision time is a way to model data and is not generally applicable to all data
I donāt have strong opinions about ādecision timeā (have yet to feel the need for it), but valid time is hugely valuable, and should be applicable to all business data. Like it should really only be an option to disregard valid time IFF your data has ~no correlation with real-world / human-scale notions of time, and you will never have a need to track changes to it.
Doltās DVCS-inspired notions of branching and diffing data sets is definitely cool, but Iām not sure how it really corresponds with how businesses typically move data around today, at least not internally within the context of a single business.
In contrast, I think the lack of recognition & adoption of valid time (and also system-time immutability) is a massive source of complexity observable across every business in existence. It is particularly obvious wherever regulatory compliance requirements crop up.
Regardless though I wish the Dolt team every success, and undoubtedly many of the ideas theyāve been pushing forward around multi-master data reconciliation/replication and forking CI builds would be great to add to XT someday.
You might also enjoy Kent Beckās explanation of bitemporality: Eventual Business Consistency - by Kent Beck
Thanks for the commentary and links!
Doltās DVCS-inspired notions of branching and diffing data sets is definitely cool, but Iām not sure how it really corresponds with how businesses typically move data around today, at least not internally within the context of a single business.
I was thinking this would be useful for content-focused products like a CMS or a knowledge base. But Iāve yet to actually try those features out.
Whereas Xtdbās handling of bitemporality would be more useful where reports are required such as ecommerce or finance.
As it happens I am very partial to CMS and knowledge base like use-cases - thatās largely what inspired my passion for databases to begin with 
Multi-master/p2p replication is an awesome ideal, and local-first UIs for knowledge work are arguably essential - my database rabbit hole started with CouchDB and āCouchAppsā(!)
However, bringing those concepts to life within mission critical business systems has generally always been non-trivial, risky and expensive vs. the centralized, non-distributed options.
Perhaps the two biggest practical barriers have been the assumptions that SQL databases have historically baked in around (1) mutability and (2) schema management. Dolt and XTDB both try to address those same barriers in very different ways, in terms of UX and also under-the-hood.
My own personal hope is that the (arguably simpler) data model in XTDB can facilitate creating similarly powerful CMS and knowledge base like systems atop - but right now that would mean implementing all the replication/diffing logic in userspace.
Iāve been thinking about this more, since knowledge/content management is a space Iām interested in.
Being able to use first-class Clojure support with Xtdb makes the idea of building such facilities on top worth considering (as opposed to using Doltās instead).
I wonder if thereās facilities Xtdb lacks (and could provide) that would make that more feasible? like database forking, etc. and leave merging/review to user space. WDYT
Asking this early in case I decide to use it for such a use-case later, ha.
I wonder if thereās facilities Xtdb lacks (and could provide) that would make that more feasible? like database forking, etc.
Definitely forking. Doing it well probably necessitates some sort of labelling/tagging + instance ID + hashing scheme. The biggest technical hurdle is likely around making structural sharing across long-lived forks efficient - although thatās potentially not a major tax / requirement if the diffs are only ever modest (MBs not GBs).
In v1 we have the with-tx API, which we do hope to recreate at some point, but real forking means making that persistent/long-lived. However maybe with-tx could be sufficient by itself for various use-cases (e.g. modest branching in CI for PRs, small diffs).
leave merging/review to user space
XTDB could help here with FDWs/multiple-DB/federated-DB queries, which would avoid pulling data into userspace to handle diffing and merging.
Incidentally I was just reading through Diffing and patching tabular data - Open Knowledge Labs - prompted by Jonathan Edwardsā latest demo vid: Experiment visualizing structure diffs ā Alarming Development
Also, you may want to keep an eye on Brimm: graph backend with a Notion-inspired UI (by Filip JurukoviÄ), Tue, Mar 12, 2024, 6:30 PM | Meetup ā¦if it wasnāt on your radar already (built on v1)
Yeah, I realize Iām underestimating complexity after reading that! Maybe itās good we have such focused databases for different use-cases.
Will be interesting to see Xtdb evolve and who knows maybe one day will also offer these features.