Limbo: A complete rewrite of SQLite in Rust

Original Article ↗ Hacker News Discussion ↗

A new project aims to reimplement the SQLite database engine in Rust, promising memory safety, asynchronous I/O, first-class WebAssembly support and deterministic simulation testing while remaining compatible with SQLite’s language and file format. Commenters are split between enthusiasm for a modern, open-contribution alternative to SQLite’s tightly controlled, C-based codebase and concern that a partial, early-stage rewrite cannot yet match SQLite’s maturity, performance in real workloads, or extensive proprietary test suite. Questions around licensing, true compatibility (especially when adding features like MVCC or stricter typing), binary size for embedded and WASM use, and the real benefits of async I/O frame the effort as high-potential but very long-term.

Motivation and Goals

  • Limbo is a from-scratch Rust reimplementation of SQLite, not a C fork, with goals of:
    • Full SQL and file-format compatibility (at least initially).
    • Memory safety, async I/O, and WASM as first‑class targets.
    • Built‑in Deterministic Simulation Testing (DST), inspired by FoundationDB/TigerBeetle.
  • Some see strong motivation for a memory‑safe SQLite‑compatible engine, especially given SQLite’s closed development model and proprietary “best” test suite.
  • Others argue SQLite is already exceptionally high quality and the last C project that “needs” a rewrite; many worse C codebases exist.

Performance and Language Choice

  • The blog cites a microbenchmark where Limbo is ~20% faster than SQLite on a trivial SELECT; critics say:
    • Single microbenchmarks on incomplete code are not meaningful.
    • Missing features and checks often explain early wins.
  • Supporters counter that:
    • Matching or approaching SQLite performance this early shows no inherent Rust penalty.
    • Modern storage and CPUs make language and architecture choices more important than “I/O dominates anyway”.

Compatibility, Forking, and Features

  • SQLite does not accept substantial external patches and uses a “cathedral” model; this is cited as a reason for independent reimplementations.
  • Limbo/libSQL are seen as “hard” forks in spirit, since they plan MVCC and other semantics that likely break ABI/shared‑memory compatibility.
  • There is interest in cleaning up SQLite “baggage” (loose typing, opt‑in foreign keys), but this conflicts with strict backward compatibility; tension here is unresolved.

Licensing and Openness

  • SQLite is public domain; Limbo is MIT and explicitly not public domain.
  • Debate centers on:
    • Whether public domain counts as “open source”.
    • Legal uncertainty of PD in some jurisdictions vs. clarity and attribution of MIT.
    • Ethics of creating more restrictively licensed derivatives of PD code.

Testing, Reliability, and Certification

  • SQLite’s extensive proprietary test suite (aiming at 100% MC/DC coverage) is both admired and criticized:
    • Admired as a reliability model and revenue source (support, certification).
    • Criticized because forks cannot easily reach parity.
  • Some note Rust’s safety guarantees change the calculus for needing that level of C‑oriented testing.

Maturity, Ecosystem, and Practical Concerns

  • Limbo is very early; many SQL features are missing, and basic operations can still panic.
  • Concerns raised:
    • Feature parity may take years; “first 90% vs second 90%” problem.
    • Binary size (Limbo ~6MB vs SQLite ~1.6MB) matters for embedded use.
    • Ecosystem fragmentation (SQLite, libSQL, DuckDB, etc.) adds cognitive load for users.