Hacker News Reader

Comment by fulafel | Hacker News Reader

They're not aiming at replacing SQLite-in-C with SQLite-in-Rust, they're doing this so they can implement more additional functionality faster than with C's chainsaw-juggling-act semantics and the inability to access the proprietary SQLite test suite.

See the features and roadmap at https://github.com/tursodatabase/turso

View on HN

IMHO breaking free of SQLite's proprietary test suite is a bigger driver than C vs Rust. Turso's Limbo announcement says exactly that: they couldn't confidently make large architectural changes without access to the tests. The rewrite lets them build Deterministic Simulation Testing from scratch, which they argue can exceed SQLite's reliability by simulating unlikely scenarios and reproducing failures deterministically.

> IMHO breaking free of SQLite's proprietary test suite is a bigger driver than C vs Rust.

I don't understand this claim, given the breadth and depth of SQLite's public domain TCL Tests. Can someone explain to me how this isn't pure FUD?

"There are 51445 distinct test cases, but many of the test cases are parameterized and run multiple times (with different parameters) so that on a full test run millions of separate tests are performed." - https://sqlite.org/testing.html

The irony is if they only had the public domain tests, no one would complain even though it would mean the exact same number of open source tests.

That’s like if I gave you half the dictionary and then said it’s ironic that if there really weren’t any letters after “M” you wouldn’t be complaining.

The next bullet point:

> 2. The TH3 test harness is a set of proprietary tests…

Of course, but how does that make the allegation not FUD?

I’m confused, the statement is that SQLite has a proprietary test suite? It does. Where’s the FUD?

Turso tried to add features to SQLite in libsqlite but there were bugs/divergent behaviour that they couldn’t reconcile without the full test suite.

The test suite that the actual SQLite developers use to develop SQLite is not open-source. 51445 open-source test cases is a big number but doesn't really mean much, particularly given that evidently the SQLite developers themselves don't consider it enough to provide adequate coverage.

There are also non-public tests.

SQLite's test suite is infamously gigantic. It has two parts: the public TCL tests you're referencing, and a much larger proprietary test suite that's 100x bigger and covers all the edge cases that actually matter in production. The public tests are tiny compared to what SQLite actually runs internally.

...why does sqlite have proprietary tests??

So that enhancements only be practical by hiring the original team.

It allows the code to be fully public domain, so you can use it anywhere, while very strongly discouraging random people from forking it, patching it, etc. Even still, the tests that are most applicable to ensuring that SQLite has been built correctly on a new compiler/architecture/environment are made open source (this is great!) while those that ensure that SQLite has been implemented correctly are proprietary (you only need these if you wanted to extend SQLite's functionality to do something different).

This allows for a business model for the authors to provide contracted support for the product, and keeping SQLite as a product/brand without having to compete with an army of consultants wanting to compete and make money off of their product, startups wanting to fork it, rename it, and sell it to you, etc.

It's pretty smart and has, for a quarter century, resulted in a high quality piece of software that is sustainable to produce and maintain.

Having seen way too many "we're going to rewrite $xyz but make it BETTERER!!", I don't give this one much chance of success. SQLite is a high-quality product with a quarter-century of development history and huge amounts of effort, both by the devs and via public use, of testing. So this let's-reinvent-it-in-Rust effort will have to beat an already very good product that's had a staggering amount of development effort and testing put into it which, if the devs do manage to get through it all, will end up being about the same as the existing thing but written in a language that most of the SQLite targets don't work with. I just can't see this going anywhere outside of hardcore Rust devotees who want to use a Rust SQLite even thought it still hasn't got past the fixer-upper stage.

How do you want to define success for this project relative to SQLite? Because they already have concurrent writes working for their rust implementation. It's currently marked experimental, but it does already work. And for a lot of people, that's all they want or need.

https://turso.tech/blog/beyond-the-single-writer-limitation-...

fragmede is correct.

I needed SQLite as a central system DB but couldn't live with single-writer. So I built a facade that can target SQLite, Postgres, or Turso's Rust rewrite through one API. The useful part: mirroring. The facade writes to two backends simultaneously so I can diff SQLite vs Turso behavior and catch divergences before production. When something differs, I either file upstream or add an equalizing shim. Concurrent writes already working is a reasonable definition of success. It's why I'm using it.

How common is this as a use case though? I wouldn't normally expect to see "SQLite" and "central system DB" in the same sentence. SQL Server, Postgres, 'Orable, MySQL, DB2, but not really something targeted for small-footprint lightweight use.

SQLite is battle-tested in production at massive scale. Discord handles millions of concurrent users with SQLite clusters. WhatsApp served 900 million users before Facebook acquired them, running on SQLite for message storage. The "lightweight" perception is outdated.

Who knows, maybe 5 years from now, you will say to yourself: that crazy wasn't so crazy after all!

In other words, they are creating their own database and hitching on to the SQLite brand to market it. (That's fine though).

I think it's fair to say they tried using SQLite but apparently had to bail out. Their use case is a distributed DBaaS with local-first semantics, they started out with SQLite and only now seem to be pivoting to "SQLite-compatible".

Building off of that into a SQLite-compatible DB doesn't seem to me as trying to piggyback on the brand. They have no other option as their product was SQLite to begin with.

No that's completely incorrect. It's compatible with SQLite, not just in the same spirit:

> SQLite compatibility for SQL dialect, file formats, and the C API

It stopped being compatible with SQLite even before the Rust rewrite: https://news.ycombinator.com/item?id=42386894

That doesn't seem very fair. It's still beta and clearly far from finished. And they do call out the compromises - they have a whole page about how they are not yet fully compatible:

https://github.com/tursodatabase/turso/blob/main/COMPAT.md

I don't think that's fine at all, it's quite a shitty thing to do hoenstly and I'm not surprised it's a VC backed company doing it.

How would you do it then?

I'd probably wouldn't ride the coattails of another open source project that provides hundreds of billions in value for free annually for anyone on this Earth in order to make a quick buck. IDK I have morals and it seems if you want VC funding you must lack them.

It's no different than the hucksters that take public domain books and slut them up in order to make some coin peddling smut.

Without the test suite isn’t even more likely to have stability problems?

Turso has its own test suite that in the repo.

but the other one has decades of engineering effort and is based on real world problems

But the other one is not available to most and SQLite itself is "open-source" not "open-contributions" so extending SQLite is pretty much impossible at scale:

- no way to merge upstream

- no way to run full test-suit to be sure everything is tiptop

Indeed. That is a problem for developing SQLite without having an agreement with the developers. That is not a problem for me choosing to use SQLite in my stack.

Maybe. It's hard to know what kind of issues that test suite covers. If memory safety is the main source of instability for the C implementation then the Rust implementation won't be too affected without the test suite. Same if it focus a lot on compatibility with niche embedded platforms and different OSes, which Turso won't care to lose.

"Stability" is a word that means different things for different use cases.

Coverage is described on the SQLite website

Not likely. The alternative was for them to modify SQLite without the test suite and no obvious indication of what they would need to do to try to fill in the gaps. Modifying SQLite with its full test suite would be the best choice, of course, but one that is apparently[1] not on the table for them. Since they have to reimagine the test suite either way, they believe they can do a better job if the tests are written alongside a new codebase.

And I expect they are right. Trying to test a codebase after the fact never goes well.

[1] With the kind of investment backing they have you'd think they'd be able to reach some kind of licensing deal, but who knows.

I don't get this. In their own rust implementation they have to write and use their own test and they still don't have access to the proprietary sqlite tests. So their implementation will necessarily be whatever they implement + whatever passes their tests. Same as it would be if they forked sqlite in C. (Plus they would have the open source tests). Am I missing something?

You are missing that HN accounts needlessly overthink everything, perhaps?

Otherwise, I doubt it. They have to write the tests again no matter what. Given that, there is no downside to reimplementing it while they are at it. All while there is a big upside to doing that: Trying to test something after the implementation is already written never ends well.

That does not guarantee that their approach will succeed. It is hard problem no matter how you slice it. But trying to reverse engineer the tests for the C version now that all knowledge of what went into it in the first place is lost is all but guaranteed to fail. Testing after the fact never ends well. Rewriting the implementation and tests in parallel increases the chances of success.

Reply on news.ycombinator.com