Curling IO's tests don't need a shared test database, cleanup hooks, or transaction tricks. Each test gets its own database, so a test can pass alone or in the full suite for the same reason: nothing else can touch its data.
That falls out of one Version 3 choice: SQLite runs in-process. Each test gets a completely independent in-memory SQLite database, cloned from a template in microseconds using SQLite's backup API.
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.
The next version of Curling IO should feel familiar: the same registrations, schedules, scoring, and club admin workflows, just faster and harder to break. The work is mostly under the surface, but the payoff is practical: fewer slowdowns at peak registration, better reliability during live events, and a platform we can keep improving for a long time.
This series explains what changes, what doesn't, and why we're making the bet.