Evan Czaplicki — the creator of Elm — spent years trying to bring “languages like Elm” to SQL, and the result is Acadia, now in public alpha. The thesis: the type mismatch between expressive languages and databases is the root cause of mountains of error-prone glue code, and a compiler can verify schemas, queries, and migrations the way it verifies the rest of the program.
Four goals drove the design:
- Precise types. Store Rust enums, Elm custom types, or Haskell ADTs in the database directly — no hand-rolled binary layouts, JSON conversions, or nullable-column compromises.
- Verified migrations. The compiler checks migrations against known schemas before they touch a live database — attacking the universal fear of running slightly-off commands against production.
- Friendly errors. Elm-grade error messages for database queries, extending the effort that inspired similar work in Rust.
- End-to-end types. Column types shared across client, server, and database — change a table and get quality errors in your Elm or Haskell code.
Mechanically, queries are written functionally (map, filter, let-bindings) and compiled to SQL at compile time — the compiler prints the SQL it generates, and transactions only commit if every step succeeded. Under the hood it is plain SQLite, with raw SQL always available as an escape hatch.
The backstory is the argument: since 2017, the problem was that “the types in our database were not quite what we wanted,” and every layer built on top spent effort converting data between formats. Czaplicki worked quietly “like a grad student” because he doubted it was possible — migrations, 1+N queries, and functional semantics in SQL all had to be solved, not assumed.
The essay’s real contribution is framing the database as the last great type-safety frontier — the one place strongly-typed codebases still degrade into handwritten conversion code, and where a compiler can finally verify what ORMs leave to runtime.