Hacker News Reader

Comment by bawolff | Hacker News Reader

I don't understand why you would want this.

You use it to write version-controlled applications, so that your structured table data gets the same collaboration and auditing benefits that your source code enjoys. This is a couple years of out date but should give you an idea for how it's being used in the real world.

https://www.dolthub.com/blog/2024-10-15-dolt-use-cases/

For DoltLite, the big use case is embedded local-first development. It's a DB you can write to locally offline, then sync to a remote server when you have connectivity. Crucially, this works in both directions, and tolerates writes from multiple offline clients by merging their changes together.

A version controlled db? Have a look at dolts main page then, it’s been around for some time - this is just adding an embedded version.

I read it, and i think i understand even less than when i started.

They’re probably a VC backed product in search of a solution.

Version controlled data is a legitimate solution to actual problems.

Care to name them?

Here are some ideas

https://www.dolthub.com/blog/2024-10-15-dolt-use-cases/

There are filesystems (ZFS and btrfs) with snapshots and this feature can be used to version-control things. They both do copy-on-write and this is pretty close to what content-addressable storage would give you in terms of compression.

With merging updates between branches?

Physical or semantic merging?

Both.

What problems does a version controlled database solves that is not solved by proper table auditing ?

not having to implement proper table auditing?

For DoltLite in particular, push/pull/clone/fetch are an elegant solution to the local-first sync problem. You can use data conflicts instead of CRDTs.

https://www.dolthub.com/blog/2026-04-27-why-doltlite/

In general, branch and merge seem to be required primitives for agentic writes. Would you let a coding agent change your code if it wasn't in Git? We think the same will apply to databases.

If you want to take a version from a database, it's usually for backup. If you want different versions in your data, you put that IN the database. Manually merging different database versions does not sound too surprising.

A VCS is useful for code, because plaintext lacks a version feature. This problem does not exist for databases, because you design the structure yourself.

> If you want to take a version from a database, it's usually for backup. If you want different versions in your data, you put that IN the database. Manually merging different database versions does not sound too surprising.

This is not primarily for backups and has been part of ml and ds work for a while. And more, but that’s where I hit it.

> This problem does not exist for databases, because you design the structure yourself.

It is entirely possible to solve a lot of this in a more generic way, so that you don’t have to solve it each time. That’s what dolt is about.

Here’s a blog post from a few years ago with some use cases from actual users

https://www.dolthub.com/blog/2024-10-15-dolt-use-cases/

Reply on news.ycombinator.com