Rethinking Database Programming

Most people did not dispute the pain points. They agreed SQL is awkward as a host-language interface, especially when queries are embedded as strings, checked late, and hard to compose. Where the conversation landed was that this does not remove the core tradeoff. The database remains the long-lived asset, SQL remains the only interface that exposes the full surface area of real engines, and any code-first abstraction eventually runs into features it cannot model cleanly. PostgreSQL partitioning, compression, custom constraints, search paths, engine-specific DDL, and migration edge cases all came up as examples of where the abstraction leaks and raw SQL returns. That pushed the thread toward a narrower position that got broad support: SQL should stay the source of truth for schema and engine capabilities, while higher-level tools can still add value by parsing SQL, generating types, and compile-time checking queries. Several people pointed to tools like sqlc and Ormin as the more believable direction because they keep native SQL in charge instead of replacing it. A second thread argued that the real target should be SQL itself, not databases. The problem is not the relational model, which many defended strongly, but SQL as a poor programmable interface with weak composability and too much stringly plumbing. The other major issue was trust. Acadia is closed source with a subscription license, and commenters saw that as a much bigger blocker than syntax or language design. The concerns were not abstract open source ideology. They were about operational dependency on a single-vendor tool with bus-factor risk, uncertainty created by Elm’s history, and alarming license language suggesting access problems when a subscription ends. Even people who liked the technical direction often framed it as something to watch, not something they would put under production data yet.