Live data from Hacker News

DoltLite: A SQLite fork with Git-style version control, built with 2k agent PRs

dolthub.com

41–50 of 65 posts

Re: DoltLite: A SQLite fork with Git-style version control, built with 2k agent PRs

#41
post #12

Earlier quoted context omitted.

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.

What problems does a version controlled database solves that is not solved by 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.

Re: DoltLite: A SQLite fork with Git-style version control, built with 2k agent PRs

#42
post #36

I'm a little more interested how they automated the process to such a degree. How do they do it? Subagents?

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

Re: DoltLite: A SQLite fork with Git-style version control, built with 2k agent PRs

#43
post #6

Why would I trust my data to a vibe coded database, over a battle tested, tested to hell and back one?

Dolt has been around for 7 years[0]. Doltlite, like most software nowadays, has been touched by LLMs, but dismissing this project as "vibe coded" seems harsh [0] - https://www.dolthub.com/blog/2019-10-14-dolt-a-simple-exampl...

[dead]

Re: DoltLite: A SQLite fork with Git-style version control, built with 2k agent PRs

#44
post #17

Earlier quoted context omitted.

> Where are you getting those figures? https://www.dolthub.com/blog/2026-06-08-how-fast-is-doltlite...

God that had a lot of llm'isms. Couldnt get through it with all the repeats and info bloat.

Dunno if I'd have directly attributed the writing to LLMs had I not read this, but I wouldn't have opened the link otherwise. Holy crap, that reads just like the documentation / explainers that I have Claude write for future agents or to remind me what I had it do in the future.

Re: DoltLite: A SQLite fork with Git-style version control, built with 2k agent PRs

#45
post #12

Earlier quoted context omitted.

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.

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/

Re: DoltLite: A SQLite fork with Git-style version control, built with 2k agent PRs

#46
post #28
post #12

Earlier quoted context omitted.

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.

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?

Re: DoltLite: A SQLite fork with Git-style version control, built with 2k agent PRs

#47
post #11

Earlier quoted context omitted.

> however it's 1.2x to 4x slower than sqlite No? Where are you getting those figures? It feels like you may have pulled that from the 125 and 400 us numbers? > The simple way to fork a sqlite db is just to copy it, but if that is too slow you could use it with a copy on write filesystem, either something native, a FUSE filesystem, or build a sqlite VFS. That wouldn’t really solve what dolt does though. > and it's lev…

> Where are you getting those figures? https://www.dolthub.com/blog/2026-06-08-how-fast-is-doltlite...

Ah yes so the 4x slower isn’t really a real world case and you’d have to explicitly measure yours - it’s not a fixed slowdown but depends on table size - and it’s for doing many many single inserts in a row, which you’d be batching either way.

Re: DoltLite: A SQLite fork with Git-style version control, built with 2k agent PRs

#48
post #47

Earlier quoted context omitted.

> Where are you getting those figures? https://www.dolthub.com/blog/2026-06-08-how-fast-is-doltlite...

Ah yes so the 4x slower isn’t really a real world case and you’d have to explicitly measure yours - it’s not a fixed slowdown but depends on table size - and it’s for doing many many single inserts in a row, which you’d be batching either way.

That's probably why they gave a range in their original comment.

Re: DoltLite: A SQLite fork with Git-style version control, built with 2k agent PRs

#49
post #46
post #28

Earlier quoted context omitted.

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?
Post reply on HN