If it works, then it’s impressive. Does it work? Looking at test.sh, the oracle tests (the ones compared against SQLite) seem to consist in their entity of three trivial SELECT statements. SQLite has tens of thousands of tests; it should be possible to port some of those over to get a better idea of how functional this codebase is.

Edit: I looked over some of the code.

It's not good. It's certainly not anywhere near SQLite's quality, performance, or codebase size. Many elements are the most basic thing that could possibly work, or else missing entirely. To name some examples:

- Absolutely no concurrency.

- The B-tree implementation has a line "// TODO: Free old overflow pages if any."

- When the pager adds a page to the free list, it does a linear search through the entire free list (which can get arbitrarily large) just to make sure the page isn't in the list already.

- "//! The current planner scope is intentionally small: - recognize single-table `WHERE` predicates that can use an index - choose between full table scan and index-driven lookup."

- The pager calls clone() on large buffers, which is needlessly inefficient, kind of a newbie Rust mistake.

However…

It does seem like a codebase that would basically work. At a large scale, it has the necessary components and the architecture isn't insane. I'm sure there are bugs, but I think the AI could iron out the bugs, given some more time spent working on testing. And at that point, I think it could be perfectly suitable as an embedded database for some application as long as you don't have complex needs.

In practice, there is little reason not to just reach for actual SQLite, which is much more sophisticated. But I can think of one possible reason: SQLite has been known to have memory safety vulnerabilities, whereas this codebase is written in Rust with no unsafe code. It might eat your data, but it won't corrupt memory.

That is impressive enough for now, I think.

▲

alt187 14 minutes ago | parent | next [-]

> But I can think of one possible reason: SQLite has been known to have memory safety vulnerabilities, whereas this codebase is written in Rust with no unsafe code.

I've lost every single shred of confidence I had in the comment's more optimistic claims the moment I read this.

If you read through SQLite's CVE history, you'll notice most of those are spurious at best.

Some more context here: https://sqlite.org/cves.html

▲

olmo23 24 minutes ago | parent | prev | next [-]

IIRC the official test-suite is not open-source, so I'm not sure how possible this is.

▲

wedog6 3 hours ago | parent | prev | next [-]

SQLite is tested against failure to allocate at every step of its operation: running out of memory never causes it to fail in a serious way, eg data loss. It's far more robust than almost every other library.

	▲	sigmoid10 2 hours ago \| parent [-]
		Unfortunately it is not so easy. If rigorous tests at every step were able to guarantee that your program can't be exploited, we wouldn't need languages like Rust at all. But once you have a program in an unsafe language that is sufficiently complex, you will have memory corruption bugs. And once you have memory corruption bugs, you eventually will have code execution exploits. You might have to chain them more than in the good old days, but they will be there. SQLite even had single memory write bugs that allowed code execution which lay in the code for 20 years without anyone spotting them. Who knows how many hackers and three letter agencies had tapped into that by the time it was finally found by benevolent security researchers.

▲

camgunz 2 hours ago | parent | prev | next [-]

I'm not impressed:

- if you're not passing SQLite's open test suite, you didn't build SQLite

- this is a "draw the rest of the owl" scenario; in order to transform this into something passing the suite, you'd need an expert in writing databases

These projects are misnamed. People didn't build counterstrike, a browser, a C compiler, or SQLite solely with coding agents. You can't use them for that purpose--like, you can't drop this in for maybe any use case of SQLite. They're simulacra (slopulacra?)--their true use is as a prop in a huge grift: tricking people (including, and most especially, the creators) into thinking this will be an economical way to build complex software products in the future.

▲

9dev an hour ago | parent | next [-]

Well--given a full copy of the SQLite test suite, I'm pretty sure it'd get there eventually. I agree that most of these show-off projects are just prop pieces, but that's kind of the point: Demonstrate it's technically possible to do the thing, not actually doing the thing, because that'd have diminishing returns for the demonstration. Still, the idea of setting a swarm of agents to a task, and, given a suitable test suite, have them build a compliant implementation, is sound in itself.

▲

gf000 an hour ago | parent | prev [-]

Also, the very idea is flawed. These are open-source projects and the code is definitely part of the training data.

	▲	viraptor 12 minutes ago \| parent \| next [-]
		This would be relevant if you could find matching code between this and sqlite. But then that would invalidate basically any project as "not flawed" really - given GitHub, there's barely any idea which doesn't have multiple partial implementations already.
	▲	tux3 23 minutes ago \| parent \| prev [-]
		That's why our startup created the sendfile(2) MCP server. Instead of spending $10,000 vibe-coding a codebase that can pass the SQLite test suite, the sendfile(2) MCP supercharges your LLM by streamlining the pipeline between the training set and the output you want. Just start the MCP server in the SQLite repo. We have clear SOTA on re-creating existing projects starting from their test suite.

▲

IshKebab an hour ago | parent | prev [-]

> I think the AI could iron out the bugs, given some more time spent working on testing

I would need to see evidence of that. In my experience it's really difficult to get AI to fix one bug without having it introduce others.