Skip to main content

Why We Chose SQLite

· 13 min read
Dave Rapin
Dave Rapin
Founder @ Curling IO
Update: October 1, 2026

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.

About this post

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.

Built for High-Traffic Curling Competitions

· 2 min read
Chris
Chris
Product @ Curling IO

Major curling competitions put very different demands on software than a typical league night. Registration can involve qualification rules and team assembly, draw schedules need to cover multiple pools and playoff formats, and live scoring traffic can spike as thousands of fans follow the same games.

Background Jobs Without the Baggage

· 7 min read
Dave Rapin
Dave Rapin
Founder @ Curling IO
Update: October 1, 2026

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.

About this post

This is a technical implementation note from the development of Curling IO v3. It is written for software engineers and goes deeper into Gleam, the BEAM, OTP, SQLite-backed queues, durability, and job execution than our usual product posts.

When a curler asks for a login email, the page should respond immediately. They shouldn't wait on Postmark, and we shouldn't run a separate worker fleet just to send a message in the background.

Curling IO Version 3 runs background jobs inside the same BEAM runtime as the web app. No Redis. No separate worker. No additional deployment. The queue is durable because pending jobs live in SQLite, not memory.

Passwordless Auth, Done Right

· 11 min read
Dave Rapin
Dave Rapin
Founder @ Curling IO
Update: October 1, 2026

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.

Curling IO has been passwordless since Version 2. No passwords to remember, no passwords to steal, no password reset flows. You enter your email, we send you a short-lived login code, and you're in. It's been working well for over a decade, and for Version 3 we're keeping the same approach while fixing some rough edges and adding multi-email support.

But first, let's talk about why we made this controversial decision in the first place.

Bilingual by Design

· 8 min read
Dave Rapin
Dave Rapin
Founder @ Curling IO
Update: October 1, 2026

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.

About this post

This is a technical architecture note about localization in Curling IO v3. It is written for software engineers and goes deeper into Fluent, compile-time translation checks, bilingual content modeling, and language routing than our usual product posts.

English and French support has to be boring. A club in Quebec shouldn't find a half-translated registration page, and an organization running national competitions shouldn't need a support ticket to catch a missing label.

Curling IO has been bilingual since Version 2, but after a decade of maintaining around 10,000 YAML translation keys, we've hit the limits of what that approach can catch: missing keys, missing translations, and unused keys that accumulate silently over time. Version 3 keeps the bilingual experience and makes more of those mistakes impossible to ship.

The Next Version of Curling IO

· 8 min read
Dave Rapin
Dave Rapin
Founder @ Curling IO
Update: October 1, 2026

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.

About this post

This is an overview of the technical foundation explored for Curling IO v3. It is written for software engineers and others interested in application architecture, and goes deeper into Gleam, the BEAM, SQLite, hosting, and scaling than our usual product posts.

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.