Why We Chose SQLite
This post reflects our earlier Gleam exploration for Curling IO v3. We ultimately chose Rust and TypeScript. Why We Chose Rust for Version 3 explains that decision and what we kept from the exploration.
This is a technical architecture note about the database decision for Curling IO v3. It is written for software engineers and operators, and goes deeper into SQLite, Litestream, database isolation, hosting, and recovery tradeoffs than our usual product posts.
Version 3 should be cheaper to operate, easier to restore, and still fast during peak registration and live scoring. That pushed us toward a choice we didn't expect: SQLite.
We assumed PostgreSQL at first. After a decade running Postgres in production, we knew the tooling, the failure modes, and the operational playbook. Then we compared self-hosting Postgres with Litestream-backed SQLite and changed our minds.