Deep dive into Turso, the "SQLite rewrite in Rust"

Posted by unsolved73 6 hours ago

Counter82Comment76OpenOriginal

Comments

Comment by ndiddy 5 hours ago

The thing that worries me the most about Turso is that rather than the small, stable team running SQLite, Turso is a VC backed startup trying to capitalize on the AI boom. I can easily see how SQLite's development is sustainable, but not Turso's. They're currently trying to grow their userbase as quickly as possible with their free open source offering, but when they have investors breathing down their necks asking about how they're going to get 100x returns I'm not sure how long that'll last. VCs generally expect companies they invest in to grow to $100 million in revenue in 5-10 years. If your use of their technology doesn't help them get there, you should expect to be rugpulled at some point.

Comment by hu3 4 hours ago

I too am weary of VC incentives but:

1) It's MIT licensed. Including the test suite which is something lacking in SQLite:

https://github.com/tursodatabase/turso

2) They have a paid cloud option to drive income from:

https://turso.tech/pricing

Comment by simonw 4 hours ago

"Including the test suite which is something lacking in SQLite"

That's not entirely true. SQLite has a TON of tests that are part of the public domain project: https://github.com/sqlite/sqlite/tree/master/test

They do have a test suite that's private which I understand to be more about testing for different hardware - they sell access to that for companies that want SQLite to work on their custom embedded hardware, details here: https://sqlite.org/th3.html

> SQLite Test Harness #3 (hereafter "TH3") is one of three test harnesses used for testing SQLite.

Comment by MobiusHorizons 4 hours ago

> 2) They have a paid cloud option to drive income from:

I’ve been confused by this for a while. What is it competing with? Surely not SQLite, being client server defeats all the latency benefits. I feel it would be considered as an alternative to cloud Postgres offerings, and it seems unlikely they could compete on features. Genuinely curious, but is there any sensible use case for this product, or do they just catch people who read SQLite was good on hacker news, but didn’t understand any of the why.

Comment by IshKebab 3 hours ago

The article talks about this. If you have a project that starts small and an in-process DB is fine, but you end up needing to scale up then you don't have to switch DBs.

Comment by iamrobertismo 4 hours ago

The MIT licensing makes this even less trustworthy. I can image a major cloud or fly.io just proprietary forking them as a service, as cloud providers have done for years.

Comment by bigstrat2003 2 hours ago

So what? The MIT licensed original will still be there, you don't lose out on anything if that happens. And also, SQLite itself is public domain, so by your logic we shouldn't trust SQLite either. Which is crazy.

Comment by iamrobertismo 2 hours ago

I don't understand you reply here. Database startups have always had the consistent issue of cloud providers providing managed solutions without contributing back. It is why many moved to or use the AGPLv3 and why there was the whole SSPL controversy in the first place. Running a successful open source database startup is not trivial. None of this applies to SQLite.

Comment by g947o 4 hours ago

Elasticsearch was license under Apache 2.0 until they switched.

That says enough.

Comment by tcfhgj 4 hours ago

to AGPL3?

Comment by sam_lowry_ 4 hours ago

> test suite which is something lacking in SQLite

You must be kidding. Last time I checked, sqlite was mostly extensive test suites.

Comment by jzebedee 3 hours ago

It's covered in the article. The full SQLite test suite isn't open source, so you (the third party) don't have the same confidence in your modifications as the SQLite team does.

Comment by HAMSHAMA 3 hours ago

I think they meant that the test suite is not open source. You’re right that it is extensive.

Comment by koverstreet 4 hours ago

Yeah, that's not a good environment for this kind of engineering. You need long term stability for a project like this, slow incremental development with a long term plan, and that's antithetical to VC culture.

On the other hand, Rust code and the culture of writing Rust leads to far more modularity, so maybe some useful stuff will come of it even if the startup fails.

I have been excited to see real work on databases in Rust, there are massive opportunities there.

Comment by g947o 4 hours ago

I was excited about this for a second until seeing your comment.

Unless you are Amazon which has the resources to maintain a fork (which is questionable by itself with all the layoffs), you probably shouldn't touch this.

Comment by mhh__ 4 hours ago

Some lessons about the modern distaste for copyleft here IMO

Comment by CodingJeebus 5 hours ago

Completely agree, I'm looking at pretty much all software this way nowadays.

We've all been around long enough to know that "free" VC-backed software always means "free... until it's in our interest to charge for it". And yet users will still complain about the rugpull in 2026, no matter how many times they've been through it. "Fool me once, shame on you"

Comment by rantingdemon 5 hours ago

This is very shallow for a supposed deep dive.

I'm not ready to entertain Turso as an alternative to something that is as battle tested as Sqlite.

Comment by floren 5 hours ago

> This is very shallow for a supposed deep dive.

I think it's time for a new law of headlines: anything labeled a "deep dive" isn't.

Comment by maxbond 3 hours ago

My law of headlines is, "don't take them too seriously, don't develop too many expectations about the article, skim the article (or the comments) to know what it is about and whether it is worth your time".

Comment by geodel 5 hours ago

Perhaps these are for deep divers who discuss Apple watch deep diving features than actual deep diving.

Comment by Havoc 5 hours ago

I’d imagine this will go a bit like the rust rewrite of sudo etc. Despite the memory safety advantages at least towards the start it still ends up more fragile because the incumbent has years of testing and fixing behind it

Comment by fulafel 5 hours ago

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

Comment by thisislife2 4 hours ago

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

Comment by dlisboa 3 hours ago

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.

Comment by IshKebab 3 hours ago

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

Comment by yencabulator 2 hours ago

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

Comment by IshKebab 1 hour ago

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

Comment by groundzeros2015 4 hours ago

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

Comment by dlisboa 3 hours ago

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.

Comment by groundzeros2015 3 hours ago

Coverage is described on the SQLite website

Comment by 0x457 4 hours ago

Turso has its own test suite that in the repo.

Comment by groundzeros2015 4 hours ago

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

Comment by 9rx 3 hours ago

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.

Comment by adamzwasserman 4 hours ago

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.

Comment by CharlesW 3 hours ago

> 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

Comment by einsteinx2 2 hours ago

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.

Comment by digitalPhonix 2 hours ago

The next bullet point:

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

Comment by CharlesW 2 hours ago

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

Comment by tracker1 4 hours ago

I definitely wouldn't be surprised by bugs and/or compatibility issues over time. Especially in the near term. I'm mixed, but somewhat enthusiastic on Turso's efforts to create client-server options and replication.

In the past I've reached for FirebirdSQL when I needed local + external databases and wanted to limit the technology spread... In the use case, as long as transactions synched up even once a week it was enough for the disparate remote connections/systems. I'm honestly surprised it isn't used more. That said, SQLite is more universal and lighter overall.

Comment by adamzwasserman 4 hours ago

Building a production app on Turso now. No bugs or compatibility issues so far. The sqlite API isn't fully implemented yet, so I wrote a declarative facade that backfills the missing implementations and parallels writes to both Turso and native sqlite: gives me integrity checking and fallback while the implementation matures

Comment by zbentley 4 hours ago

Isn’t the rust rewrite deployed as part of some fairly significant Linux distros these days?

That’s hearsay that I haven’t dug into, so I may well be wrong.

Comment by ktimespi 4 hours ago

Ubuntu is deploying it in a non-LTS release, and they're trying to get the bugs out of the way is what I'm hearing

Comment by uwemaurer 5 hours ago

I recently benchmarked different SQlite implementations/driver for Node. Better-sqlite3 came out on top of this test: https://sqg.dev/blog/sqlite-driver-benchmark/

Comment by kevinfiol 4 hours ago

This reflects my experience. I also experienced very bad memory leaks when using libSQL for large write jobs. Haven't tried tursodatabase yet, but my impression by the confusing amount of packages in the Turso ecosystem is it's not ready for primetime yet.

Comment by sauercrowd 5 hours ago

> ... most of which can be fixed by a rewrite in Rust

huh? That is clearly not the case. memory bugs - sure. Not having a public test suite, not accepting public contributions, weakly typed columns and lack of concurrency has nothing to do with the language. They're governance decisions, that's it.

>I see this situation trhough the prism of the innovator's dilemma: the incumbent is not willing to sacrifice a part of its market to evolve, so we need a new player to come and innovate.

I don't think the innovators dilemma quite applies in the open source world. Projects are tools, that's it. Preserving a project for the sake of preserving it isn't a good idea.

If people need to run a sqlite db in these exotic places, shedding it means someone else has to build their own tool now that can do it. Sqlite has decided that they care about that, so they support it, so they can't use rust. Seems sound.

Projects coming and going is a good thing in open source, not a bug.

Comment by jayd16 5 hours ago

Maybe they're saying a rewrite part solves the governance issues not the rust part.

Comment by overfeed 4 hours ago

That'd be an interesting attitude towards governance for a VC-funded startup with -- I presume -- VC-controlled board seats.

Comment by rendaw 5 hours ago

I know I've seen multiple bug reports in open source projects with "well we can't fix this because it'd break things for existing users." Maybe it's a bad thing, but why do you think this doesn't happen?

Comment by jancsika 5 hours ago

> lack of concurrency has nothing to do with the language

That's an extraordinary claim for any C codebase.

Unless it ships with code enabling concurrency that is commented out, we should assume that "concurrency in C ain't easy" was a factor in that design choice.

Comment by gus_massa 5 hours ago

I was surprised that the test suit not open source. Some info in https://sqlite.org/testing.html

It looks like some parts are open source and other not. Does anyone know more about the backstory? (It looks like one is a custom program that generate fuzz test. Do they sell it to others SQL engines?)

Comment by Rendello 34 minutes ago

The CoRecursive episode with SQLite creator D. Richard Hipp goes through it. I've linked to the part of the transcript that covers it, the key quote being:

> We still maintain the first one, the TCL tests. They’re still maintained. They’re still out there in the public. They’re part of the source tree. Anybody can download the source code and run my test and run all those. They don’t provide 100% test coverage but they do test all the features very thoroughly. The 100% MCD tests, that’s called TH3. That’s proprietary. I had the idea that we would sell those tests to avionics manufacturers and make money that way. We’ve sold exactly zero copies of that so that didn’t really work out. It did work out really well for us in that it keeps our product really solid and it enables us to turn around new features and new bug fixes very fast.

https://corecursive.com/066-sqlite-with-richard-hipp/#testin...

Comment by blibble 5 hours ago

it's their business model

it's free

but if you want the compliance paperwork, you pay for it

Comment by dodomodo 3 hours ago

usefull if you need to validate that the database runs properly on yours embedded platform, possibly with its custom io and sync primitives.

Comment by tln 5 hours ago

Where is the "networked mode" in Turso? Turso's readme and docs do not mention anything like this

Comment by 5 hours ago

Comment by maxmcd 4 hours ago

They're implementing MVCC

Comment by gcr 5 hours ago

[flagged]

Comment by 5 hours ago

Comment by TeaVMFan 4 hours ago

For the Java ecosystem, H2 fills this gap nicely, easily handling both in- memory and remote JDBC access:

https://frequal.com/java/TheBestDatabase.html

Comment by adzm 5 hours ago

I hate to be negative, but where is the deep dive? This is a shallow overview of Turso's features and some of the motivation behind it. Am I missing something?

Comment by eviks 5 hours ago

It's longer than a tweet

Comment by IshKebab 3 hours ago

Good article though it kind of stopped just when I thought the deep dive was about to start.

Comment by 9rx 6 hours ago

> A database that can scale from in-process to networked is badly needed

Why not Postgres? https://pglite.dev

Comment by rudedogg 5 hours ago

From what I’ve read there’s a pretty sizable performance gap between SQLite and pglite (with SQLite being much faster).

I’m excited to see things improve though. Having a more traditional database, with more features and less historical weirdness on the client would be really cool.

Edit: https://pglite.dev/benchmarks actually not looking too bad.. I might have something new to try!

Comment by 6 hours ago

Comment by causalscience 6 hours ago

[flagged]

Comment by avhception 6 hours ago

Did you actually click the link? pglite aims to be embeddable just like sqlite.

Comment by roywiggins 6 hours ago

pglite runs in wasm so it should be possible to embed it where you want, like sqlite?

Comment by duped 5 hours ago

Why would I want wasm for an embedded database? It's not a feature, quite an anti-feature frankly.

edit: it looks like pglite is only useful for web apps

Comment by evertheylen 4 hours ago

Not really, I used it to develop against a "real" postgres database for a node backend app. It worked fine and made it pretty easy to spin up a development/CI environment anywhere you want. Only when inserting large amounts of data you start to notice it is slower than native postgres. I had to stop using it because we required the postgis extension (although there is some movement on that front!).

Comment by 9rx 4 hours ago

> it looks like pglite is only useful for web apps

Where else other than web apps (herein meaning network-attached database servers that, more often than not, although not strictly so, use HTTP as the transport layer) are at meaningful risk of bumping up against SQLite write contention? If your mobile/desktop app has that problem, it is much more likely that you have a fundamental design issue and not a scaling problem.

Comment by duped 2 hours ago

I'm not sure I follow what that has to do with embedding a database into your application

Comment by 9rx 1 hour ago

In a networked environment, which includes the web, it is typical to expose your database over the network. In the olden days clients started speaking SQL over the network, but there are a number of pitfalls to this approach. SQL was designed for use on mainframes, which, understandably, does not translate to the constraints of the network very well.

To alleviate the pressure of those pitfalls, we started adding middle databases (oft called web apps, API services, REST services, etc.) that proxied the database through protocols that are more ideal to the realities and limitations of the network. Clients were then updated to use the middle database, seeing the hacks required to make SQL usable over the network to be centralized in one spot, greatly reducing the management burden.

But having two database servers is pretty silly when you think about it. Especially when the "backend" database's protocol isn't suitable for the network[1]. Enter the realization that if you use something like SQLite, you don't need another, separate database server. You can have one database server[1] that speaks a network friendly API. Except SQLite itself has a number of limitations that doesn't make it well suited to being the backing engine of your network-first DBMS.

That is what the article is about — Pointing out those limitations, and how Turso plans to overcome them. If your use case isn't "web app", SQLite is already going to do the job just fine.

[1] After all, if it were suited for networks, you wouldn't need the middle service. Clients would already be talking to that database directly instead.

[2] As in one logical database server. In practice, you may use a cluster of servers to provide that logical representation.

Comment by groundzeros2015 4 hours ago

You don’t want another server but you do want networking?

Comment by 6 hours ago

Comment by gethly 4 hours ago

let's play a little game known as "count the unsafe"

https://github.com/search?q=repo%3Atursodatabase%2Fturso%20u...

Comment by sgammon 5 hours ago

Wow what a terrible and misleading article

Comment by 5 hours ago

Comment by yunohn 6 hours ago

What a breath of fresh air to read a blog not written by AI, with actual human learnings and opinions. Thanks for the write up!

Comment by w-m 5 hours ago

At the current rate of progress I'm wondering how long it will take for llm agents to be able to rewrite/translate complete projects into another language. SQLite may not be the best candidate, due to the hidden test suite. But CPython or Clang or binutils or...

The RIIR-benchmark: rewrite CPython in Rust, pass the complete test suite, no performance regressions, $100 budget. How far away are we there, a couple months? A few years? Or is it a completely ill-posed problem, due to the test suite being tied to the implementation language?

Comment by bathtub365 5 hours ago

What’s the point?

Comment by w-m 4 hours ago

A clearly defined/testable long-horizon task: demonstrating the capability of planning and executing projects that overrun current llm's context windows by several orders of magnitude.

Single-issue coding benchmarks are getting saturated, and I'm wondering when we'll get to a point where coding agents will be able to tackle some long-running projects. Greenfield projects are hard to benchmark. So creating code or porting code from one language to another for an established project with a good test suite should make for an interesting benchmark, no?