Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

dolthub.com

Post reply on HN
Print view View original

51–60 of 65 posts

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

#51

Post by zachmu »

bawolff wrote: post #7

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.

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

#52

Post by nagaiaida »

OskarS wrote: post #39
WatchDog wrote: post #5

So the main feature of this project is that it's easy to fork a database, however it's 1.2x to 4x slower than sqlite, and it's level of testing and validation will be nothing like sqlite. 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 would probably be faster to bui…

> The simple way to fork a sqlite db is just to copy it SQLite recommends against doing that [1] while a transaction is active, because the copy might have some pre/post data in it which could potentially cause corruption. Presumably this isn't an issue with copy-on-write filesystems assuming they copy atomically, but I probably still wouldn't do it, instead use the backup API or VACUUM INTO (if nothing else, because…

if you don't trust something to survive an atomic filesystem snapshot, why would you trust it to survive sudden power loss?

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

#53

Post by IanCal »

grebc wrote: post #22
bawolff wrote: post #16

Earlier quoted context omitted.

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.

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

#55

Post by OskarS »

nagaiaida wrote: post #52
OskarS wrote: post #39

Earlier quoted context omitted.

> The simple way to fork a sqlite db is just to copy it SQLite recommends against doing that [1] while a transaction is active, because the copy might have some pre/post data in it which could potentially cause corruption. Presumably this isn't an issue with copy-on-write filesystems assuming they copy atomically, but I probably still wouldn't do it, instead use the backup API or VACUUM INTO (if nothing else, because…

if you don't trust something to survive an atomic filesystem snapshot, why would you trust it to survive sudden power loss?

That's what I'm saying, if you have a CoW filesystem, backing up with atomic snapshots is almost certainly fine, SQLite's advice against copying probably doesn't apply to that. But just typing `cp` in a terminal is probably not a good idea if a transaction is active (even if you're on a CoW filesystem, `cp` in experience usually isn't atomic without some flags).

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

#57

Post by joelwallis »

It's wonderful to see people trying to fork SQLite in any way possible, to supposedly build a better product with AI, out of smt that's been built by seriously talented people for over 20 years.

Kudos to the team behind SQLite. These people built smt absolutely amazing!

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

#58

Post by joelwallis »

vonnieda wrote: post #10

Psyched to see this! I've been working on my own similar thing that sucks and I don't want to - I want to write a local first music app that syncs across all my devices. This might get me there!

Unrelated to the post – but if you're trying to build smt that "magically syncs" across devices, you'd like to use CouchDB (and it's front end companion, PouchDB). They solve this problem for you, and it's solved in a very, very reliable way for years!

FWIW, search [and research] about offline-first apps. Lots of gems in this niche!

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

#60

Post by zachmu »

louis-lau wrote: post #37
solarkraft wrote: post #26

Earlier quoted context omitted.

If going through a strongly designed process with quality gates is vibe coding, I guess so. I thought the term was reserved fir “claude, make this happen” style development and the term for the more professional approach was “agentic development”, though this seems to be another layer higher. Grouping it all under “vibe coded” loses precision. Sure, it uses AI, but differently from other projects and with different i…

Agentic development still requires human review and human ownership of PRs. This is vibe coded. Seems precise to me.

You can call it what you want I guess, but "vibe coded" around these parts is a simple pejorative, it means the authors don't know what the code does and the product is poor quality.

Most successful agent-coded projects have a few essential features that it's worth calling out: 1) The human driving it has real domain expertise; 2) There's an oracle for correctness; 3) The agent has a real-world example to copy, adapt, or translate.

This project had all these elements. The human driving the agent understood the technical and product decisions that make a version-controlled database work, because he's been doing that for 8 years. The project uses the existing 5.7M query test suite for SQLite3 as its oracle, as well as adapted versions of Dolt's extensive test suite to verify the version-control features that SQLite has no tests for. And the agent had a human-written implementation of the core product (Dolt) to crib from.

All of this is to say: yes, agents wrote this code, but if you or another randomly chosen software engineer sat down and tried to duplicate this result you wouldn't succeed. You wouldn't know what the agent had gotten wrong at every step of development, or even what questions to ask to find out where the errors might be. Despite the existence of a correctness oracle, the agent on its own cannot iterate to 100% correctness without a domain expert steering it. And that expert also has to have an extensive understanding of the existing code base that's being copied. You can't just say "Claude, implement version control in SQLite3, make no mistakes", it's not going to work.

Post reply on HN