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.

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.

assuming your malloc function returns NULL when out of memory. Linux systems don't. They return fake addresses that kill your program when you use them.

That's not how Linux memory management works, there are no poison values. Allocations are deferred until referenced (by default) and when a deferred allocation fails that's when you get a signal. The system isn't giving you a "fake address" via mmap.

My interpretation of the GP comment is that you are saying the same thing. Linux will return a pointer that is valid for your address space mappings, but might not be safe to actually use, because of VM overcommit. Unixes in general have no way to tell the process how much heap can be safely allocated.

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.

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

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.

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.

Even if was copying sqlite code over, wouldn't the ability to automatically rewrite sqlite in Rust be a valuable asset?

Not really because it's not possible for SQLite written in Rust to pass SQLite's checks. See https://www.sqlite.org/whyc.html

That doesn't seem to support your claim; guessing you mean:

> "2. Safe languages insert additional machine branches to do things like verify that array accesses are in-bounds. In correct code, those branches are never taken. That means that the machine code cannot be 100% branch tested, which is an important component of SQLite's quality strategy."

'Safe' languages don't need to do that, if they can verify the array access is always in bounds at compile time then they don't need to emit any code to check it. That aside, it seems like they are saying:

    for (int i=0; i<10; i++) {
        foo(array[i]);
    }

in C might become the equivalent of:

    for (int i=0; i<10; i++) {
        if (i >= array_lower && i < array_higher) {
            foo(array[i]);
        } else {
            ??? // out of bounds, should never happen
        }
    }

in a 'safe' language, and i will always be in inside the array bounds so there is no way to test the 'else' branch?

But that can't be in SQLite's checks as you claim, because the C code does not have a branch there to test?

Either way it seems hard to argue that a bounds test which can never fail makes the code less reliable and less trustworthy than the same code without a bounds test, using the argument that "you can't test the code path where the bounds check which can never fail, fails" - because you can use that same argument "what if the C code for array access which is correct, sometimes doesn't run correctly, you can't test for that"?

Correct, that's what I mean. I trust SQLite's devs to know more about this, so I trust what they wrote. There are parts of Rust code that are basically:

  do_thing().expect(...);

This branch is required by the code, even if it can't be reached, because the type system requires it. It's not possible to test this branch, therefore 100% coverage is impossible in those cases.

The type system does not require that. You can just discard the result:

  let _ = do_thing();

Except that doesn’t work if you need to use the result…

You normally count/test branches at the original language level, not the compiled one. Otherwise we'd get VERY silly results like:

- counting foo().except() as 2 branches

- counting a simple loop as a missed branch, because it got unrolled and you didn't test it with 7,6,5,4,3,2,1 items

- failing on unused straight implementation of memcpy because your CPU supports SIMD and chose that alternative

Etc. The compiled version will be full of code you'll never run regardless of language.

That’s not my requirement, that’s SQLite’s requirement. If you want to dispute their claim, I recommend you write to them, however I strongly suspect they know more about this than you do.

I know it's on the sqlite side. I'm familiar with the claim and disagree with it.

You’re arguing in this context:

> wouldn't the ability to automatically rewrite sqlite in Rust be a valuable asset?

If you want to rewrite SQLite, you must accept their position. Otherwise you simply aren’t rewriting SQLite, you’re writing your own database.

Not having bound checks does not make sqlite sqlite. If that was the case, you couldn't compile it with https://clang.llvm.org/docs/BoundsSafety.html turned on and still call it sqlite for example.

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.

If you minimax for passing the SQLite test suite, I’m still not sure you’ll have a viable implementation. You can’t prove soundness of code through a test suite alone.

> I'm pretty sure it'd get there eventually.

Why? The combinatorics of “just try things until you get it right” makes this impractical.

Sure, but that presumes that you have that test suite written without having a single line of application code written (which, to me, is counterintuitive, unrealistic, and completely insane)

SQLite apparently has 2 million tests! If you started only with that and set your agentic swarm against it, and the stars aligned and you ended up with a pristine, clean-room replica that passes everything, other than proof that it could be done, what did you achieve? You stood on the shoulders of giants to build a Bizarro World giant that gets you exactly back to where you began?

I'd be more interested in forking SQLite as-is, setting a swarm of agents against it with the looping task to create novel things on top of what already exists, and see what comes out.

[0] https://en.wikipedia.org/wiki/SQLite#Development_and_distrib...

You think an implementation of SQLite in another language, with more memory safety, has no value?

I agree that this current implementation is not very useful. I would not trust it where I trust SQLite.

Regardless, the potential for having agents build clean room implementations of existing systems from existing tests has value.

agreed!

I'm generally not this pedantic, but yeah, "I wrote an embedded database" is fine to say. If you say "I built SQLite", I expected to at least see how many of the SQLite tests your thing passed.

> tricking people (including, and most especially, the creators),

I believe it's an ad. Everything about it is trying so hard to seem legit and it's the most pointless thing I have ever seen.

sorry for misleading, added an update stating that this is a simulacra of sqlite

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

Have it maintain and run a test suite.

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

You do not recall correctly. There is more than 500K SLOC of test code in the public source tree. If you "make releasetest" from the public source tarball on Linux, it runs more than 15 million test cases.

It is true that the half-million lines of test code found in the public source tree are not the entirety of the SQLite test suite. There are other parts that are not open-source. But the part that is public is a big chunk of the total.

Out of curiosity, why aren't all tests open source?

One set of proprietary tests is used in their specialist testing service that is a paid for service.

What is that service used for besides SQLite?

It's still SQLite, they just need to make money: https://sqlite.org/prosupport.html

Edit: also this:

> TH3 Testing Support. The TH3 test harness is an aviation-grade test suite for SQLite. SQLite developers can run TH3 on specialized hardware and/or using specialized compile-time options, according to customer specification, either remotely or on customer premises. Pricing for this services is on a case-by-case basis depending on requirements.

That's interesting. Here is more information https://sqlite.org/th3.html

The roots of SQLite are in defence industry projects of US Navy and General Dynamics. Seems like TH3 might be of interest for these sort of users.

One could assume also for Fossil.

> 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

I am using sqlite in my project. It definitely solves problems, but I keep seeing overly arrogant and sometimes even irresponsible statements from their website, and can't really appreciate much of their attitude towards software engineering. The below quote from this CVE page is one more example of such statements.

> All historical vulnerabilities reported against SQLite require at least one of these preconditions:

> 1. ...

> 2. The attacker can submit a maliciously crafted database file to the application that the application will then open and query.

> Few real-world applications meet either of these preconditions, and hence few real-world applications are vulnerable, even if they use older and unpatched versions of SQLite.

This 2. precondition is literally one of the idiomatic usage of sqlite that they've suggested on their site: https://sqlite.org/appfileformat.html

> That is impressive enough for now, I think.

There are lot of embedded SQL libraries out there. I'm not particularly enamoured with some of the design choices SQLite made, for example the "flexible" approach they take to naming column types, so that isn't why I use it.

I use it for one reason: it is the most reliable SQL implementation I know of. I can safely assume if file corruption, or invariants I tried to keep aren't there, it isn't SQLite. By completely eliminating one branch of the failure tree, it saves me time.

That one reason is the one thing this implementation lacks - while keeping what I consider SQLite's warts.