September 2026 Summaries

No summary generated yet.

SQLite intentionally provides no built-in encryption because it treats databases as files and leaves protection to applications or operating systems, a design that led third-party extensions to rely on the unsupported SQLITE_HAS_CODEC hook until its removal in SQLite 3.32.0 in 2020. SQLCipher remains the established open-source option, particularly for mobile deployments, but can require difficult version migrations and uses AES-256-CBC with HMAC; the proprietary SQLite Encryption Extension (SEE) offers official SQLite-project maintenance and several cipher modes but limits source auditability, while SQLite3MultipleCiphers emerged after the codec-hook removal to support current SQLite releases and legacy SQLCipher compatibility. These tools generally encrypt databases page by page, leaving SQLite’s first 100-byte header readable while using unique nonces and authentication tags stored in reserved page space to provide authenticated encryption and detect tampering. The discussion compares AES-GCM for broad compliance recognition, AEGIS for high performance on hardware supporting AES instructions but without NIST approval, and ChaCha20-Poly1305 for devices without such hardware acceleration. It argues that traditional solutions remain suitable for single-user or embedded databases but were not designed for cloud-native bring-your-own-key systems, large-scale per-tenant key isolation, or newer cipher choices, making newer engines such as Turso worth evaluating for projects with those requirements.