timsehn

After about three weeks I hand drove three agents in parallel for 8-10 hours/day. There is very little automation.

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.

I'm the CEO of a company that's focused on version control for structured data ie. SQL tables and JSON documents. We share the "version control for everything" vision and think an agentic world needs it.

https://www.dolthub.com/

I’m the author of the linked Prolly Tree article and I launched a prolly tree visualizer last week.

Conveniently: https://www.prollytree.com

Thanks for being an early adopter. We learned a lot trying to support your use case and you’re still customers so it can’t have been too bad…

We actually wrote another blog about this because I had the same question. I am the CEO of DoltHub so I can have my engineers write stuff to explain it to me :-)

https://www.dolthub.com/blog/2025-06-26-prolly-tree-balance/

We built a MySQL-compatible one and are building a Postgres-compatible one :-) Free and open source.

https://github.com/dolthub/dolt

We use the reset functionality to speed up our tests.

https://www.dolthub.com/blog/2022-06-10-enginetest-perf/

Coming soon we'll have the ability to replicate a branch HEAD to MySQL as well.

Version Control is not the type of thing "mainstream DBs would adopt".

We needed to build a custom storage engine to make querying and diffing work at scale:

https://docs.dolthub.com/architecture/storage-engine

It based on the work of Noms including the data structure they invented, Prolly Trees.

https://docs.dolthub.com/architecture/storage-engine/prolly-...

Most direct users of go-mysql-server use it to test Golang <> MySQL interactions without needing a running server.

We here at DoltHub use it to provide SQL to Dolt.

> Why is Dolt MySQL flavored?

TLDR; Because go-mysql-server existed.

https://www.dolthub.com/blog/2022-03-28-have-postgres-want-d...

We have a Postgres version of Dolt in the works called Doltgres.

https://github.com/dolthub/doltgresql

We might have a go-postgres-server package factored out eventually.

You can do this with a setting:

https://docs.dolthub.com/sql-reference/version-control/dolt-...

So you can do local first with the `dolt_clone()`, `dolt_remote()`,`dolt_fetch()`, `dolt_pull()`, and `dolt_push()` procedures:

https://docs.dolthub.com/sql-reference/version-control/dolt-...

as well as the `dolt_remotes` system table:

https://docs.dolthub.com/sql-reference/version-control/dolt-...

We have a ton of remote options:

https://docs.dolthub.com/sql-reference/version-control/remot...

Right now, DoltHub (https://www.dolthub.com/) will still work as a remote but all the SQL there will be the MySQL version. Over time the Doltgres storage format may become more bespoke and we'll have to figure out how DoltHub will work.

Queries on DoltHub need to go to S3 to fetch all the chunks. This only works for databases < 1GB generally. You will get much better performance if you clone the database locally.

The insurance database (transparency in coverage) is here (also open data):

https://www.dolthub.com/repositories/dolthub/transparency-in...

If you clone the database locally it will work. It takes a long time to clone though.

If you are just looking for data versioning there is Dolt:

https://github.com/dolthub/dolt

And that has a user-friendly UI in DoltHub:

https://www.dolthub.com/

You wouldn't store the images themselves in Dolt, those would likely be links to S3 but al the labels and surrounding metadata could be stored in Dolt?

DISCLAIMER: I'm the CEO of DoltHub so this is self-promotion.

Founder of DoltHub here. One of my team pointed me at this thread. Congrats on the launch. Great to see more folks tackling the data versioning problem.

Dolt hasn't come up here yet, probably because we're focused on OLTP use cases, not MLOps, but we do have some customers using Dolt as the backing store for their training data.

https://github.com/dolthub/dolt

Dolt also scales to the 1TB range and offers you full SQL query capabilities on your data and diffs.

This is just a database of hospital price URLs. If you want actual prices we have that as well but it's from the beginning of the year:

https://www.dolthub.com/repositories/dolthub/hospital-price-...

Posted this in our Discord :-)

Creator of Dolt here. Thanks for the mention! My cofounder is writing a blog on Monday about how to run Dolt embedded like SQLite.

Glad to see more people exploring the space.

Creator here.

It's slower. This is `sysbench` Dolt vs MySQL.

https://docs.dolthub.com/sql-reference/benchmarks/latency

We've dedicated this year to performance with a storage engine rewrite. We'll have some performance wins coming in the back half of the year. We think we can get under 2X MySQL.

It also requires more disk. Each change is at least on average 4K on disk. So, you might need more/bigger hard drives.

Creator here.

You only connect with a MySQL-client. There is no MySQL code in it. Here's the story if you're curious.

https://www.dolthub.com/blog/2022-03-28-have-postgres-want-d...

We will eventually build a Postgres Foreign Data Wrapper.

We're trying to close the performance gap. Current performance on sysbench can be found here:

https://docs.dolthub.com/sql-reference/benchmarks/latency

We're even slower on heavy transactional use cases.

We're dedicating the year to it and we think we can get under 2X MySQL. We have customers who switched from other No-SQL DBs and actually got faster so getting close to MySQL is a great accomplishment.

Creator here...

Only need Oracle clients but we will eventually have a Postgres foreign data wrapper for the storage engine. I explain how we ended up MySQL in this blog post if you're curious.

https://www.dolthub.com/blog/2022-03-28-have-postgres-want-d...

Creator here...

We are a fork of Noms. Lots of incremental changes and we're in the process of a major storage engine overhaul (what we use Noms for) for performance as we speak.

One of the creators here... Indeed. Intentional.

https://docs.dolthub.com/other/faq#why-is-it-called-dolt-are...