🤖 SQLite: considered alternatives, staying (2026-07-10)

Decision: lchat stays on SQLite via modernc.org/sqlite. Alternatives were considered (prompted by discomfort with the SQLite core team's public persona — the Benedictine "Code of Ethics" page) and rejected. Don't re-litigate this without new facts; the escape hatch to watch is noted below.

Why we looked

The SQLite team's Code of Ethics (the Rule of St. Benedict, adopted by D. Richard Hipp partly as a statement against boilerplate CoCs) gives some people pause. Context that defused it: it governs the three-person core team only, not users or contributors, and the code itself is public domain — no license terms, nothing ideological attaches to the artifact. Our build dependency is also one step removed already: modernc.org/sqlite is Jan Mercl's machine translation of the C source into pure Go.

Alternatives rejected

• libSQL (Turso) — the real "same engine, different governance" option: MIT, open-contribution fork, same file format + SQL. Rejected because its Go bindings (go-libsql) require cgo, which breaks the single-static-binary CGO_ENABLED=0 deploy that the whole per-instance architecture rests on. Turso's ground-up Rust rewrite (ex-"limbo") is not production-ready and also not Go-native.
• Pure-Go KV stores (bbolt, Badger, Pebble) — no SQL; every query in db.go becomes hand-rolled index management.
• Pure-Go SQL engines (chai/genji) — nowhere near SQLite's testing pedigree; unacceptable as the sole datastore of an E2EE messenger.
• Postgres — ends the one-file, one-disk deploy model.

If this ever needs revisiting

The trigger would be governance becoming a practical problem (licensing change, abandonment) — not the ethics page. First option to re-check: libSQL's cgo situation (a pure-Go or no-cgo binding would make it a near-drop-in). File format compatibility means migration would be low-drama.