The most interesting argument in a new essay on modern relational query languages is not about syntax at all. The author, a developer with background in MySQL and Db2, wants sum types, pattern matching, and discriminated unions in the query language itself. That is a demand aimed at the type system, not the parser. And it is the demand most likely to matter for AI builders, because the data shapes that break SQL today are the same data shapes that break data pipelines feeding models tomorrow.
The essay, published August 19, was an old draft revived by recent discussions of new query languages like Acadia. It lists seven wants: better syntax, a functional programming orientation, less opaque query planners, better user-defined types, sum types and pattern matching, multi-type foreign keys, and a few more. The syntax complaints are familiar and mostly cosmetic. The author admits as much, noting programmers “are like toddlers, they want their Kraft Dinner and not the broccoli.” The real substance sits in the middle of the list.
The strongest concrete example is the IBM i stack frame problem. IBM i exposes SQL functions for system administration under its Services umbrella, and the author shows how stack trace data comes back as a single table with mutually exclusive column groups, heavy nullables, and string fields that are effectively enums. The proposed fix is a FrameType that is a discriminated union of record types: ILE, OPM, AIX, Java, each with different fields. Pattern matching then filters rows cleanly: where AIX { Bitness: 64 } = FrameType. A non-matching call is a compile-time error, not a runtime null check.
This is not an aesthetic preference. It is a structural critique of how SQL models data that is naturally shaped like a tagged union. The essay’s point is that the relational model, as Codd described it in The Relational Model, supports domains and richer types, but most implementations treat them as sugar around ranges and checks. Postgres is the notable exception, a heritage the author traces back to Ingres and QUEL, which was closer to Codd’s vision than SQL itself. Oracle reportedly added domain support only recently.
For AI infrastructure, the stakes are direct. The messy reality of machine learning data is full of exactly these shapes: observations with optional fields, events that take different payloads depending on type, provenance records that reference one of several entity kinds. Today, that data gets flattened into wide tables with nulls, or shoved into JSONB columns, or moved out of the database entirely into Parquet files processed by Spark or DuckDB. The essay’s multi-type foreign key example, an ObjectPictures table that can reference a Software, Version, or Download row through a single ObjectID column, is a miniature version of the polymorphic association problem that every content platform eventually hits.
The essay is honest about its limits. The examples are illustrative, not prescriptive. The author has not used Postgres domains or Oracle’s new support deeply enough to judge them in practice. The IBM i example partly reflects poor schema design. But the direction is clear: a query language that lets you express a tagged union natively, and match against it with compiler-checked exhaustiveness, would eliminate an entire class of null-handling bugs that plague SQL code today.
The second most important want is better query planners. The essay calls MySQL’s EXPLAIN tools especially bad, and notes Oracle is “surprisingly good” at reporting what it expects. This matters more than it might seem. As databases absorb more AI workloads, query planning is becoming a machine learning problem in its own right. Learned cardinality estimation, plan hinting via ML, and AI-assisted index recommendation are all active research areas. A query language with a less opaque planner would make those systems easier to build and audit. If the planner is a black box, then an AI that tunes queries is tuning against a black box.
There is a cultural argument buried in the essay too. It notes that SQL’s declarative nature is close to functional programming paradigms like lazy evaluation, but most dialects optimized for 1980s procedural programs, and stored procedures pushed users toward mutable state and cursors. “Defaults matter,” the author writes. That observation has a direct parallel in the AI stack. The default way to move data into a model today is still a Python script that pulls rows, mutates them in memory, and writes them out. A query language that made functional transformation natural at the database level would move that work closer to the data, reducing the ETL pipeline’s surface area.
The essay’s syntax proposals are the weakest part, and the author knows it. Basing syntax on F#, Erlang, and Elixir is a reasonable guess at what a modern audience might accept, but syntax is the least durable layer of a language. Rust’s success shows that a language with C-like syntax can still embrace functional ideas. The type system is what survives.
None of this is likely to happen inside SQL itself. The standard moves slowly, and the installed base is enormous. What is more plausible is what the essay’s own framing suggests: new query languages, Acadia included, will compete on exactly these axes. If a new language ships with real sum types, pattern matching, and a planner that explains itself, it will not need to win over the MySQL installed base. It will win over the developers building the next generation of data infrastructure, the ones who are already writing Spark UDFs in Scala and wondering why the database cannot do this natively.
The essay ends with a quiet observation that doubles as a thesis: collapsing mutually exclusive columns into a single typed field makes data easier to visualize, because there is less scrolling left and right. That is a small win. The bigger win is that a query language which models data the way it actually is, as a union of possibilities rather than a grid of nulls, would make the entire AI data pipeline less error-prone. The null check that disappears at query time is a bug that never reaches the training set.
The question now is whether the next query language treats sum types as a headline feature or as an afterthought. The essay’s wishlist suggests the former. The history of SQL suggests the latter will take another decade.