Why SQLite Is Implemented in C

SQLite has been implemented in portable C since its first release on 2000-05-29, and there are no current plans to port the engine to another language. The decision hinges on four core attributes that C uniquely satisfies: 1. **Performance** - C is often described as “portable assembly.” It allows developers to write machine‑level code with minimal overhead while remaining cross‑platform. - Benchmarks such as *Internal vs. External BLOBs* and *35 % Faster Than the Filesystem* confirm that SQLite’s performance can only be matched—or exceeded—by code written in C. 2. **Compatibility** - Every system provides a stable ABI for C, enabling libraries written in C to be invoked from virtually any programming language. - Mobile ecosystems illustrate this: * Android Java applications still call into SQLite via a thin JNI layer. * iOS applications written in Objective‑C or Swift can import SQLite directly because Swift and Objective‑C lack native interop with Java. 3. **Low‑Dependency Footprint** - The minimal SQLite build requires only four standard C library routines—`memcmp()`, `memcpy()`, `memmove()`, and `memset()`—plus a handful of other string and memory helpers. - Even the “complete” build adds just a few allocation helpers and basic file system calls, keeping the binary size and runtime dependencies small compared to languages that ship with megabyte‑sized runtime environments. 4. **Stability and Maturity** - C is a battle‑tested language: its semantics have remained stable for decades, which is vital when the underlying engine must not change its ABI between releases. - A database engine that needs to be embedded in countless applications benefits from the predictability and rigorous error handling that the C ecosystem provides. ## Why SQLite Wasn’t written in an object‑oriented language Historically, developers entertained the idea of using C++ or Java. However, the practical realities of language interop proved prohibitive. A C++ library is only naturally usable by C++ callers, requiring elaborate bindings for other languages. Java, once a promising choice, was still maturing in the early 2000s, and its lack of native interop with established mobile platforms further limited reach. Object‑oriented design is a paradigm, not a requirement. Procedural code in C can express the same abstractions with less overhead, and for SQLite’s algorithmic core—transaction handling, B‑tree navigation, and query planning—a procedural approach yields clearer, more maintainable logic. ## Why a “safe” language hasn’t been adopted Safe programming languages such as Rust, Go, or newer systems languages were born after SQLite’s inception. While they mitigate typical bugs like memory leaks and out‑of‑bounds accesses, they impose runtime checks that introduce branch churn and complicate high‑coverage testing—a key part of SQLite’s quality assurance. Moreover, SQLite is engineered to recover gracefully from out‑of‑memory (OOM) conditions; current safe languages generally abort on OOM, conflicting with SQLite’s resilience strategy. Until a language can demonstrate: - Mature, stable ABI compatible with all target platforms, including embedded devices without an OS; - Capability to produce object code that rivals C in speed and offers 100 % branch coverage testing; - A reliable OOM recovery model; …it will not replace C for SQLite. In summary, C remains the optimal single choice: it delivers the speed, portability, minimal dependencies, and long‑term stability that a tiny, ubiquitous database engine like SQLite demands.