You’ve probably spent hours formatting a massive SQL query, meticulously aligning the JOINs and indenting the WHERE clauses until it looks like a piece of digital poetry. You step back, admire your work, and declare it ‘readable.’
But let’s be honest with ourselves for a second. We don’t love SQL because it’s readable; we love it because we’ve suffered through it long enough to call the trauma ‘expertise’.
Recently, a new language called Prela dropped, promising ‘a better SQL in 11 lines of code.’ The developer community immediately split into warring factions. One camp clutched their pearls, insisting that SQL’s verbosity is actually a feature. ‘SQL that’s formatted well is beautiful to read,’ one commenter argued. ‘My brain enjoys it.’
Then there were the pragmatists, pointing out that Prela looks a lot like pandas or datalog. Someone even brought up Sixth Normal Form (6NF) and column stores. They’re all circling the same unspoken truth, but they’re missing the actual point of the tension.
The debate isn’t about line counts. It’s about cognitive load.
SQL is declarative. You tell the database what you want, and it figures out how to get it. This is SQL’s greatest superpower, but it’s also its most insidious trap. By hiding the data flow, SQL forces you to mentally compile the execution plan backwards from the syntax. You’re doing row-wise relational algebra in your head, translating abstract logic into a guess about what the machine is actually doing.
SQL hides the data flow to protect you from the metal. Prela exposes it to make you faster.
Prela isn’t just a more compact syntax. It represents a fundamental shift in mental models. Instead of treating queries as row-wise relational algebra, Prela treats them as column-wise shape transformations. You aren’t just filtering rows; you’re reshaping the data’s physical structure. When a commenter noted that Prela feels like ‘column store’ vs ‘understanding the actual storage mechanisms,’ they hit the nail on the head.
When you look at Prela, you might feel a flash of panic. That’s the fear of being left behind by a better technology, mixed with the comfort of defending the familiar tool you already master. It’s easier to dismiss it as a ‘fluent API looking ORM’ than to admit that our sacred cow might just be a local optimum.
Yes, Prela makes assumptions about storage visible. It forces you closer to the metal, inlining operators and exposing the columnar structure. To the SQL purist, this feels dirty. To the systems engineer, this is liberation.
Your verbosity isn’t a feature. It’s a coping mechanism for a mental model that was designed in the 1970s.
If you’re evaluating next-generation data tools, stop counting lines of code. Ask yourself: Does this language make the data flow obvious, or does it hide it behind a wall of declarative syntax? The future of querying isn’t about writing less SQL. It’s about thinking in shapes, not rows.
FAQ
Q: Isn't SQL's declarative nature better because the optimizer handles the execution?
A: Yes, SQL's optimizer is great, but it forces you to guess the execution path. Prela inlines operators and exposes the columnar structure, trading blind trust for predictable performance closer to the metal.
Q: What's the practical implication of this for developers?
A: Stop optimizing for the SQL syntax you memorized a decade ago. If you're building data-intensive tools, exploring column-wise shape transformations could unlock massive performance and clarity gains over traditional row-wise logic.
Q: Is SQL's verbosity actually a bad thing if it's universally understood?
A: It's only 'universally understood' because we've spent decades forcing it into our brains. SQL's verbosity is a cognitive band-aid; we only find it readable because we've Stockholm-syndromed ourselves into accepting relational algebra as the only way to think about data.