We make Dolt, the first SQL database with Git-style version control. We’re really passionate about what we’re making so it excites us when other people are passionate too. And we love it when people talk about us; who wouldn’t?

Better Stack is a company that makes cloud observability tools and offers cloud monitoring as a service. They also have a YouTube channel where they make videos about other cloud and database software. And last month, they made a video about us!

The Reaction#

I personally thought the video was pretty well-done. The host¹ does a good job of explaining what Dolt is and how it can be used, and walks through a simple demo. He even gives a shout out to Prolly Trees, the hot new-ish data structure that makes Dolt possible. (We’re kind of obsessed with Prolly Trees, and we talk about them all the time.)

But while the host was pretty excited, viewers were a bit more mixed:

The common sentiment seemed to be that every possible use case of Dolt was already covered by some combinations of migrations, replicas, transactions, and logs. And after reviewing the video with that sentiment in mind, it was easy to see why people came to this conclusion. The video starts with a hypothetical database crisis that could be solved with a simple rollback. And the demo showcases a standard workflow of creating a change, reviewing a change, and committing it. This is a workflow that’s pretty easy to implement without Dolt just with transactions.

And while the host floats the idea of being able to dolt blame to see who edited a row, he doesn’t give an example that can’t be accomplished with logging or standard history tracking. And while he gives lip service to more sophisticated use cases such as manual PR reviews and having multiple live branches, none of these features get showcased in the demo.

The Case for Dolt#

If I had to pitch a demo that’s simple but still showcases Dolt’s usefulness, I’d go for something like this: you get a bug report and want to make a branch of your database that exactly matches the state of the database at some point in the past. dolt branch accomplishes this in O(1) time without needing to replay history. Or if you know that some change to your database exposed a bug in your app and you need to find out which one, you can do a binary search akin to git bisect, again without needing to replay history or make copies of tables.

In this blog, we’ve talked extensively about the use cases that we’ve seen from customers.. We’ve advocated for Dolt as a means of data isolation on multi-user database servers. We’ve explored how the distributed, replicated nature of Git-style remotes can solve novel permissions problems. We’ve discussed how Dolt’s data structure primitives provide the ability to compare versions, merge changes, and do rollbacks in a way that’s asymptotically faster than traditional replicas., while also avoiding duplication in storage, even with a large number of commits.

None of those make an easy byte-sized demo. But they’re real use cases that make Dolt more capable and more scalable than traditional options.

We want to thank Better Stack for engaging with us and making their demo. We’re glad people are talking about Dolt. Anyone who has any questions about Dolt’s features and capabilities should absolutely join our Discord and discuss it with us in person. We’re all real human beings who are passionate about what we’re building and will happily talk your ear off.

And a sincere thank you to everyone who engages with the idea that databases should be version controlled. Until next time.

Footnotes#

1. I feel weird just calling him “the host”, but neither the video nor the channel credits him. He might be AI-generated. ↩