Deep dive into Turso, the “SQLite rewrite in Rust”

Article reception and “deep dive” criticism

• Many readers found the post shallow relative to its “deep dive” title: mostly feature overview and motivation, lacking benchmarks, detailed architecture, binary/extension compatibility, or networked-mode specifics.
• Some liked the human, opinionated tone and the SQLite/C–Rust discussion, but others called the piece misleading or incomplete, saying it ended just as it got interesting.

What Turso is trying to be

• Turso is framed as a SQLite-compatible database that can scale from in-process to networked, adding features like concurrency, replication, and sharding while preserving SQLite’s dialect, file format, and C API.
• Confusion remains about the exact “networked mode,” as docs and README reportedly don’t clearly describe it.

Rust rewrite vs SQLite in C

• Supporters argue Rust simplifies adding complex features (concurrency, distributed behavior) compared to C, and that the rewrite enables new testing approaches (deterministic simulation) without relying on SQLite’s proprietary test suite.
• Critics counter that most problems cited (governance, contributions, typing, concurrency design) are not language issues. They also question whether a Rust rewrite can match SQLite’s decades of testing and real-world hardening.
• Some see Turso as effectively a new database trading on SQLite’s compatibility/brand; views differ on whether that’s acceptable.

SQLite’s testing and proprietary components

• A major thread is the fact that SQLite’s full test harness (especially TH3 and other non-public tests) is proprietary, even though a huge public test suite exists.
• One side argues Turso’s “we lacked the full tests” rationale is overblown or FUD, since public tests are extensive and TH3 is mainly a business add-on.
• The other side stresses that lacking the exact tests SQLite uses does constrain confident invasive changes, making a clean-room implementation plus new tests more appealing.

Reliability, maturity, and performance

• Strong skepticism about using a young, SQLite-compatible Rust DB in production, given SQLite’s 25-year track record.
• Some early users report success but acknowledge incomplete API coverage and “beta” status. Others report issues with related projects (e.g., libSQL) and say Turso’s ecosystem feels immature.
• There’s also a meta-complaint about constant “rewrite in Rust” trends: best case is “same thing, new bugs.”

VC model, licensing, and trust

• Several comments distrust VC-backed infrastructure: expectation of hypergrowth and future “rug pulls” once users are locked in.
• Counterpoints note Turso is MIT-licensed (including its tests) with a paid cloud offering, so self-hosting and forking remain possible.
• Others worry MIT licensing makes it easier for big clouds to outcompete Turso’s own service, making its business survival uncertain, though that’s framed as a Turso problem more than a user problem.

Use cases and competition

• Intended niche: apps that start with in-process SQLite and later need concurrent writes, replication, or multi-node scaling without a full database migration.
• Critics call this a narrow and somewhat uncommon path; if you anticipate needing those features, they argue you’d typically start with PostgreSQL or another established server DB.
• Some question Turso’s networked product vs just using Postgres, Firebird, H2, or other embedded/remote-capable databases.

Wider ecosystem themes

• Discussion touches on Rust’s suitability for databases, the difficulty of concurrency in C, and distaste for ORMs and leaky abstractions.
• There’s concern that constant novelty (e.g., “rewrite in Rust”) undermines long-term stewardship exemplified by SQLite’s small, stable team and highly disciplined engineering culture.