Limbo: A complete rewrite of SQLite in Rust

Original Article ↗ Hacker News Discussion ↗

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.