[HN Gopher] Deep dive into Turso, the "SQLite rewrite in Rust"
___________________________________________________________________
Deep dive into Turso, the "SQLite rewrite in Rust"
Author : unsolved73
Score : 92 points
Date : 2026-01-29 14:51 UTC (8 hours ago)
(HTM) web link (kerkour.com)
(TXT) w3m dump (kerkour.com)
| 9rx wrote:
| _> A database that can scale from in-process to networked is
| badly needed_
|
| Why not Postgres? https://pglite.dev
| rudedogg wrote:
| 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!
| yunohn wrote:
| 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!
| tln wrote:
| Where is the "networked mode" in Turso? Turso's readme and docs
| do not mention anything like this
| maxmcd wrote:
| They're implementing MVCC
| sauercrowd wrote:
| > ... 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.
| jayd16 wrote:
| Maybe they're saying a rewrite part solves the governance
| issues not the rust part.
| overfeed wrote:
| That'd be an interesting attitude towards governance for a
| VC-funded startup with -- I presume -- VC-controlled board
| seats.
| rendaw wrote:
| 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?
| jancsika wrote:
| > 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.
| adzm wrote:
| 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?
| eviks wrote:
| It's longer than a tweet
| Havoc wrote:
| 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
| fulafel wrote:
| 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
| thisislife2 wrote:
| In other words, they are creating their own database and
| hitching on to the SQLite brand to market it. (That's fine
| though).
| dlisboa wrote:
| 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.
| IshKebab wrote:
| 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
| yencabulator wrote:
| It stopped being compatible with SQLite even before the
| Rust rewrite:
| https://news.ycombinator.com/item?id=42386894
| IshKebab wrote:
| 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.m
| d
| adamzwasserman wrote:
| 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.
| CharlesW wrote:
| > _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
| einsteinx2 wrote:
| 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.
| digitalPhonix wrote:
| The next bullet point:
|
| > 2. The TH3 test harness is a set of proprietary
| tests...
| CharlesW wrote:
| Of course, but how does that make the allegation not FUD?
| groundzeros2015 wrote:
| Without the test suite isn't even more likely to have
| stability problems?
| 0x457 wrote:
| Turso has its own test suite that in the repo.
| groundzeros2015 wrote:
| but the other one has decades of engineering effort and
| is based on real world problems
| dlisboa wrote:
| 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.
| groundzeros2015 wrote:
| Coverage is described on the SQLite website
| 9rx wrote:
| 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.
| tracker1 wrote:
| 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.
| adamzwasserman wrote:
| 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
| zbentley wrote:
| 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.
| ktimespi wrote:
| 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
| SpecialistK wrote:
| Of all the projects which may benefit from a rewrite or re-
| imagining in a memory-safe language, I'm really puzzled why
| it's heavily-tested, near-universally-deployed software such as
| sudo (use oBSD doas instead?), the coreutils, and sqlite.
| Havoc wrote:
| I don't think there is a big picture plan. It requires that
| someone care both about rust and the thing
|
| ...which is a pretty arbitrary combination
| w-m wrote:
| 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?
| bathtub365 wrote:
| What's the point?
| w-m wrote:
| 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?
| ndiddy wrote:
| 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.
| CodingJeebus wrote:
| 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"
| hu3 wrote:
| 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
| g947o wrote:
| Elasticsearch was license under Apache 2.0 until they
| switched.
|
| That says enough.
| tcfhgj wrote:
| to AGPL3?
| MobiusHorizons wrote:
| > 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.
| IshKebab wrote:
| 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.
| MobiusHorizons wrote:
| Thanks. Serves me right for commenting without reading
| the article.
| iamrobertismo wrote:
| 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.
| bigstrat2003 wrote:
| 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.
| iamrobertismo wrote:
| 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.
| MobiusHorizons wrote:
| I think the point is that that sounds like a potential
| problem for turso, but it's not really a problem for
| everyone else unless some sort of vendor lockin would
| prevent using open source alternatives. But given the
| strong compatibility story with the SQLite file format
| implied already that just doesn't seem credible.
| simonw wrote:
| "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.
| sam_lowry_ wrote:
| > test suite which is something lacking in SQLite
|
| You must be kidding. Last time I checked, sqlite _was_ mostly
| extensive test suites.
| jzebedee wrote:
| 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.
| HAMSHAMA wrote:
| I think they meant that the test suite is not open source.
| You're right that it is extensive.
| cozzyd wrote:
| Are there any VC-funded open source projects that didn't
| attempt rug pulls? (There must be, right?)
| curuinor wrote:
| metabase.com, but metabase is intended for business analyst
| types and is AGPL, with shenanigans for embedding and an
| enterprise edition thing
| g947o wrote:
| 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.
| koverstreet wrote:
| 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.
| saidnooneever wrote:
| where do you see these opportunities? i didnt see a lot of
| issues personally rust would be better at than C in this
| domain. care to elaborate? (genuinely curious!)
|
| personally i see more benefit in rust for example as ORM and
| layers that talk to the database. (those are often useful to
| have in such an ecossystem so you can use the database safe
| and sanely, like python or so but then u know, fast and
| secure.)
| koakuma-chan wrote:
| You need to be crazy to use an ORM. I personally think that
| even SQL is redundant. I would like to see a high quality
| embedded database written in Rust.
| mhh__ wrote:
| Some lessons about the modern distaste for copyleft here IMO
| rantingdemon wrote:
| 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.
| floren wrote:
| > 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.
| maxbond wrote:
| 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".
| geodel wrote:
| Perhaps these are for deep divers who discuss Apple watch deep
| diving features than actual deep diving.
| gus_massa wrote:
| 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?)
| blibble wrote:
| it's their business model
|
| it's free
|
| but if you want the compliance paperwork, you pay for it
| dodomodo wrote:
| usefull if you need to validate that the database runs properly
| on yours embedded platform, possibly with its custom io and
| sync primitives.
| Rendello wrote:
| 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...
| sgammon wrote:
| Wow what a terrible and misleading article
| uwemaurer wrote:
| 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/
| kevinfiol wrote:
| 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.
| TeaVMFan wrote:
| For the Java ecosystem, H2 fills this gap nicely, easily handling
| both in- memory and remote JDBC access:
|
| https://frequal.com/java/TheBestDatabase.html
| gethly wrote:
| let's play a little game known as "count the unsafe"
|
| https://github.com/search?q=repo%3Atursodatabase%2Fturso%20u...
| IshKebab wrote:
| Good article though it kind of stopped just when I thought the
| deep dive was about to start.
| dang wrote:
| Related. Others?
|
| _Turso is an in-process SQL database, compatible with SQLite_ -
| https://news.ycombinator.com/item?id=46677583 - Jan 2026 (102
| comments)
|
| _Beyond the SQLite single-writer limitation with concurrent
| writes_ - https://news.ycombinator.com/item?id=45508462 - Oct
| 2025 (70 comments)
|
| _An adventure in writing compatible systems_ -
| https://news.ycombinator.com/item?id=45059888 - Aug 2025 (12
| comments)
|
| _Introducing the first alpha of Turso: The next evolution of
| SQLite_ - https://news.ycombinator.com/item?id=44433997 - July
| 2025 (11 comments)
|
| _Working on databases from prison_ -
| https://news.ycombinator.com/item?id=44288937 - June 2025 (534
| comments)
|
| _Turso SQLite Offline Sync Public Beta_ -
| https://news.ycombinator.com/item?id=43535943 - March 2025 (67
| comments)
|
| _We will rewrite SQLite. And we are going all-in_ -
| https://news.ycombinator.com/item?id=42781161 - Jan 2025 (3
| comments)
|
| _Limbo: A complete rewrite of SQLite in Rust_ -
| https://news.ycombinator.com/item?id=42378843 - Dec 2024 (232
| comments)
| ivanjermakov wrote:
| How SQLite is tested -
| https://news.ycombinator.com/item?id=46303277
___________________________________________________________________
(page generated 2026-01-29 23:00 UTC)