We will rewrite SQLite. And we are going all-in
turso.tech
turso.tech
The current C implementation of SQLite is likely already very safe in its unmodified form due to its extensive testing, but anyone wanting to make modifications/extensions would have a hard time maintaining that guarentee when those test suites appear to be largely proprietary and hidden behind a $120K/year subscription[0].
I've really been enjoying contributing and watching the project continue to gain traction. Excited to see where this goes.
#1:
I would like to see some sort of guarantee by Turso that they plan on sticking to an MIT or Apache license and don't plan on re-licensing to AGPL or non-OSI-approved licenses.
Some context – the founders of Turso were early employees at ScyllaDB (phenomenal Cassandra rewrite, powering Apple, Discord, etc). I'm speculating on how much influence they had over the licensing of the database, but ScyllaDB was kept under an AGPL license during their ~8 year tenure there. However, ScyllaDB still rug pulled their license and switched to enterprise-only in 2024 [1].
I also run a venture-backed startup with an open-source product (Apache 2.0), so I completely understand the pressures that cause these decisions. A rug pull with something like Limbo seems very tangible as Turso competitors like Cloudflare D1 start making cloud-based SQLite a commodity.
Regardless, we're avoiding touching libSQL or Limbo because we've already been burned by Nomad (BSL relicense), Redis (SSPL relicense), and CockroachDB (custom enterprise relicense); all of which affect our ability to keep an Apache 2.0 license. (e.g. AGPL is a viral license that affects us to change our license if we use software like Minio.)
It's worth noting that Limbo does not have a CLA, which is a good indicator that they intend to keep Limbo licensed permissively.
#2:
One big focus of Limbo (and libSQL) is the WASM-based extensions for user-defined functions. Postgres also has a powerful UDF system because users need to be able to define custom logic without an extra network hop between client <-> database. However, SQLite runs on the same machine as the code that's querying it, so it doesn't make sense to make the database heavier to allow UDF when there's already a ~0-latency way of providing extensions.
Frankly, this feels a lot like Turso investing in features to match the constraints of Turso Cloud. Turso Cloud can't run arbitrary code, so they need to implement user logic in to the database itself.
I'd much rather a Supabase-like approach: provide vanilla Postgres-as-a-service and add Auth/PostgREST/Realtime/Functions/etc as a separate bundled service instead of rewriting Postgres itself. Similarly, Neon innovated on Postgres' storage architecture, but still provides full compatibility.
StarbaseDB [2] is taking the Supabase-like approach with SQLite, and I'm really excited for this. They're leveraging Cloudflare Durable Objects + SQLite to do things like provide a native auth & rate limiting & sharding & Stripe integration in to the database without modifications to SQLite itself.
#3:
I'm not looking forward to the fracturing of the SQLite ecosystem – similar to what happened with the enshittification of the MySQL ecosystem with MariaDB or NodeJS when io.js forked off. This is not a comment against Limbo itself, just something that's inevitably going to happen.
---
To be clear – despite these concerns, I'm very excited for Limbo for:
- The new governance model
- Heavier investment in to SQLite tooling
- Promote SQLite-in-the-cloud
- Promoting local-first database architectures
Props to the engineering team for their work on this (esp the DST) and the founders/management to green-light such an ambitious project.
[1] https://www.scylladb.com/2024/12/18/why-were-moving-to-a-sou...