Against SQL

https://news.ycombinator.com/rss Hits: 3
Summary

TLDR The relational model is great: A shared universal data model allows cooperation between programs written in many different languages, running on different machines and with different lifespans. Normalization allows updating data without worrying about forgetting to update derived data. Physical data independence allows changing data-structures and query plans without having to change all of your queries. Declarative constraints clearly communicate application invariants and are automatically enforced. Unlike imperative languages, relational query languages don't have false data dependencies created by loop counters and aliasable pointers. This makes relational languages: A good match for modern machines. Data can be rearranged for more compact layouts, even automatic compression. Operations can be reordered for high cache locality, pipeline-friendly hot loops, simd etc. Amenable to automatic parallelization. Amenable to incremental maintenance. But SQL is the only widely-used implementation of the relational model, and it is: This isn't just a matter of some constant programmer overhead, like SQL queries taking 20% longer to write. The fact that these issues exist in our dominant model for accessing data has dramatic downstream effects for the entire industry: The core message that I want people to take away is that there is potentially a huge amount of value to be unlocked by replacing SQL, and more generally in rethinking where and how we draw the lines between databases, query languages and programming languages. Inexpressive Talking about expressiveness is usually difficult, since it's a very subjective measure. But SQL is a particularly inexpressive language. Many simple types and computations can't be expressed at all. Others require far more typing than they need to. And often the structure is fragile - small changes to the computation can require large changes to the code. Can't be expressed Let's start with the easiest examples - things that can't be e...

First seen: 2025-10-25 18:31

Last seen: 2025-10-25 20:33