Things I want in a modern relational query language

Every few years, someone posts a manifesto about how SQL is fundamentally broken and we need a new relational query language. They're not wrong, but they're also missing the point. SQL isn't just a language—it's an ecosystem. It's the SQLite in your phone, the Postgres in your stack, the Oracle holding up a bank's entire transactional history. You can't just declare a better syntax and expect the world to adopt it, because the value isn't in the syntax—it's in the decades of tooling, drivers, ORMs, and DataDog dashboards built around it. The article's wishlist is reasonable, but it's a wishlist for a world that doesn't exist yet. The real problem with SQL isn't the language itself—it's the impedance mismatch between what we want to express and what the language forces us to say. Want to compose queries? Good luck, you're fighting the grammar. Want to debug a complex query? Hope you like reading stack traces that look like hieroglyphics from a civilization that never learned to write. The author is right to call out composability and error messages as pain points. Those aren't just annoyances—they're the reasons people end up with 500-line SQL monstrosities generated by Eloquent or Entity Framework, which are worse in their own way. But here's the thing nobody wants to say: the problem isn't SQL, it's that we keep trying to shoehorn modern developer expectations onto a language designed in the 1970s for terminals and green screens. The relational model is sound. The implementation is what's aging. Modern query languages like the ones this author is dreaming about aren't going to replace SQL wholesale. They'll either be layered on top (like GraphQL has been for APIs, for better or worse) or they'll be embedded in new databases that nobody adopts because the switching cost is too damn high. Source: https://sporks.space/2026/08/19/things-i-want-in-a-modern-relational-query-language/ Ultimately, this article joins a long list of "SQL is bad, here's my better idea" posts that get 19 points on Hacker News and then fade into the ether. The author has good instincts—composability, better errors, cleaner semantics—but without a concrete implementation and a migration path, it's just a wishlist. And wishes don't ship. The closest we've gotten is tools like SQLAlchemy or the ORM layer, which are still SQL under the hood, and the closest we've gotten to a true replacement might be something like Datalog, and that's been relegated to academic curiosity. The relational query language of the future won't be invented—it'll be evolved, one ugly layer at a time, and it'll still be called SQL. ---