Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- I'm a little more interested how they automated the process to such a degree. How do they do it? Subagents?by oreally
- After about three weeks I hand drove three agents in parallel for 8-10 hours/day. There is very little automation.by timsehn
- The biggest limitation I see is the absence of a Go client. I know this opens a can of worms, but using ncruces/wasm2go, or just coordinating with ncruces/go-sqlite3 might work.by OutOfHere
- Everything touching this ecosystem (Gas Town, Dolt, Beads) seems like the absolute nadir of vibecoded slop
This specific community has been a Schelling point for some of the worst engineering practices I've ever seen and a desire to abstract away all details of code to LLM personas like the "Refinery" and "Deacon"
by nylonstrung - Pre 2020 HN reading this would be stoked.by michelangelo
- But post 2020 HN contains 70% AI related posts on the front page such that the moment it is revealed that something is connected to AI, the excitement seems to falter (understandably so).by sureglymop
- I don't understand why you would want this.by bawolff
- 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.by IanCal
- 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.
by zachmu - 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!
by joelwallis - 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!by vonnieda
- 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!
by joelwallis - Did I read that correctly that there’s no WAL?by grebc
- Would be good, but why not to vibe code this database myself if I had a problem with my current database?by SipitenoMK
- You’d have to do the relevant R&D and maintain the product.by solarkraft
- I let agents do their things but I would not trust them with my data without extensive validation. A database efforts main product is not exotic data structures but validation.by anon291
- One of the reasons SQLite was mostly stable over the years was it sand-boxed its closed developer environment, and clearly defined the project scope. While controversial, they did not have to deal with common accountability issues associated with screening anonymous malicious and or incompetent clown PR. =3by Joel_Mckay
- Why would I trust my data to a vibe coded database, over a battle tested, tested to hell and back one?by vrighter
- Look at dev process (i did), this think is "tested to hell" and "battle tested".
But the feedback loop was automated and accelerated. Instead of 1000 loops spread over 20 years, it had 1000 loops over a few months.
Calling it "vibe coded" just shows something about you, not the project. It is not production ready yet, but that is not for fast ai dev or for technical reasons. It needs independent reviews, independent verification, and reputation.
by throw234259 - Battle tested and tested to hell, maybe yes. But still horrible insecure architecture, with read-only access being able to write. And totally insecure full text search. https://github.com/rurban/hardsqliteby rurban
- 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...
by dekelpilli - 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 build, faster to run, and easier to validate.
by WatchDog - > 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 level of testing and validation will be nothing like sqlite.
They’re using the other dolt tests as well as the SQLite tests. Nothing will hit the level of real world testing SQLite does.
by IanCal - > 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 VACUUM INTO will also obviously VACUUM the copy).
If you're not attached/writing to it, then of course it's fine.
[1]: https://www.sqlite.org/howtocorrupt.html#_backup_or_restore_...
by OskarS - It's easy to do a VFS that handles instant forking (snapshots).
Here's an in-memory one I made (pretty useful for unit tests): https://github.com/ncruces/go-sqlite3/tree/main/vfs/mvcc
The problem DoltLite solves is merging, not forking.
by ncruces