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

31–40 of 65 posts

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

#31

Post by esperent »

grebc wrote: post #21
throw234259 wrote: post #19

Earlier quoted context omitted.

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…

Battle tested means deployed in production . So when you say battle tested earlier, and then not production ready later - which one is it?

That's selling it short. You could deploy something to production in minutes. Battle tested implies it's been not only deployed, but heavily used in all kinds of scenarios, and in the case of sqlite, probably by millions of different apps.

But anyway I assume that random name green account above is just a pro-vibe coding bot.

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

#32

Post by 1718627440 »

IanCal wrote: post #12
bawolff wrote: post #7

I don't understand why you would want this.

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.

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

#33

Post by nylonstrung »

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"

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

#34

Post by rurban »

vrighter wrote: post #6

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

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/hardsqlite

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

#35

Post by grebc »

esperent wrote: post #31
grebc wrote: post #21

Earlier quoted context omitted.

Battle tested means deployed in production . So when you say battle tested earlier, and then not production ready later - which one is it?

That's selling it short. You could deploy something to production in minutes. Battle tested implies it's been not only deployed, but heavily used in all kinds of scenarios, and in the case of sqlite, probably by millions of different apps. But anyway I assume that random name green account above is just a pro-vibe coding bot.

It’s ridiculous how common the bots are becoming, then again Sam’s put a lot of money on the line so can’t be having bad vibes.

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

#37

Post by louis-lau »

solarkraft wrote: post #26
Skinney wrote: post #15

Earlier quoted context omitted.

> Doltlite, like most software nowadays, has been touched by LLMs, but dismissing this project as "vibe coded" seems harsh From the article, at the end of the second paragraph: > Could a team of agents pull it off? It only took about 2,000 pull requests but DoltLite going Beta proves a team of agents certainly could. The first PR was merged March 17th. "vibe coded" seems pretty fitting

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.

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

#38

Post by zmmmmm »

darkfloo wrote: post #30
IanCal wrote: 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 ?

not having to implement proper table auditing?

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

#39

Post by OskarS »

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 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_...

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

#40

Post by sureglymop »

michelangelo wrote: post #13

Pre 2020 HN reading this would be stoked.

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