Article 79D9A Built to bend: Postgres’s inventor and a steward on what AI really needs

Built to bend: Postgres’s inventor and a steward on what AI really needs

by
David Gordon
from www.theregister.com - Articles on (#79D9A)
Story Image

Michael Stonebraker introduced Postgres(R) at Berkeley in 1986. Forty years later, the database he invented is a leading choice for a generation of AI projects, and he is among the sharpest skeptics of how those projects are being built. Bruce Momjian is cofounder and core team member of the PostgreSQL Global Development Group, and he works at EnterpriseDB (EDB). In upcoming episodes of AI & Data Horizons by EnterpriseDB (EDB), the Turing Award winner and MIT professor and the Postgres community advocate both make the case that the future belongs to systems that bend without breaking, and to communities that no single company controls.

Zero, not 80

Stonebraker's first exhibit is text-to-SQL, the promise that a business user can ask a question in plain English and get an answer from the warehouse. Public benchmarks such as Spider and BIRD report accuracy above 80 percent. His team tried the same thing on MIT's own data warehouse-1,400 tables of student, faculty, building, and salary information-using real queries from its SQL log.

We got zero-percent accuracy. Not 80, not 70, not 40-zero," he said. Adding agentic AI, retrieval, and prompt engineering lifted that level into the teens. Telling the model every table and join term reached the 30s. Still not ready for prime time."

The reasons are the stuff of every enterprise estate. There is no training data, because the warehouse is not on the public internet. The data is idiosyncratic: among other things, MIT buildings have numbers, not names. The schema has rotted into cryptic table and column names and overlapping views. And real queries are harder than benchmark ones. His team has published its own benchmark, Beaver, and says nobody has broken out of accuracy levels in the 30-percent range.

Use the model for what it's good at

The deeper problem, Stonebraker argues, is architectural. Large language models are good with text, but what they are no good at is doing joins of structured data," which is most of what an enterprise holds. Working with the city of Munich's transport department, Stonebraker's team found that answering a single citizen complaint about crosswalk timing meant combining regulations, CAD drawings, trolley schedules, and school-zone maps. Orchestrating that with a language model at the center was, he said, ridiculously expensive."

The team's answer, a system called Rubicon, uses models only on text, then casts the results into tables and hands the rest to a tabular engine. The orchestrator looks like a query optimizer." Stonebraker says it is cheaper by a factor of 10 and considerably more accurate than agent frameworks built around a model.

He expects agentic AI to slide from the top of the hype cycle into the valley of despair before a more balanced view emerges. Enterprises hate non-determinism: Approve a loan and reverse it on review, and that's called a lawsuit." Organizations also need protection from rogue agents. The guardrails inside the database, he notes, largely exist already: decades of access control, complete logs, and triggers that can stop a transaction in its tracks. Data-heavy agents, he suggests, belong inside the data layer as user-defined functions, if the tooling to debug and version them improves.

Stonebraker is equally blunt about the frontier. The models have already used the real training data on the internet, and he knows of no enterprise that will let a model train on its proprietary data. AGI, he said, is basically marketing hype" from foundation model vendors justifying their valuations.

Nobody owns it

Why Postgres? Postgres is the intergalactic answer to open source," Stonebraker said. Its unique feature is that it's not controlled by any one company." EDB, Microsoft, Google, and others each contribute committers, and nobody steers. He dates its rise to Oracle buying MySQL, when everybody said: vendor control." For enterprises, that independence is the foundation of sovereignty: retaining control over how and where their data systems operate.

Momjian describes the same structure from the inside. Postgres has no office, no assets, and no legal entity, yet it produces software better than billion-dollar companies." Its forecasting tool is the community itself, which spots needs early from China, Russia, and the United States. We only need one person in the world to be supersmart, and that person to tell us what they think."

Built to bend

Both experts describe a design philosophy that favors flexibility over the last few percent of speed. Stonebraker built Postgres to be extended, and that is why it absorbed JSON, full-text search, GIS, and now AI without a rewrite. Momjian adds a second call from the 1990s: Lean on the operating system rather than absorb it, which made Postgres a natural fit for the cloud.

Momjian resists optimizations that buy 5 or 10 percent at the cost of rigidity, since a mistuned system can lose 40 percent. If you take a Formula One car to the supermarket, there's no place for the groceries." The project plans on a horizon few vendors can match. We're looking at what would be the impact 5 years from now, 10 years from now."

What PostgreSQL 19 delivers

The new release puts that discipline on show. Several previewed features, including SQL property graph queries and partition merging and splitting, were reverted, because reliability comes first. AI-assisted review is finding problems quickly; the August 2026 patch release for PostgreSQL 18 addressed 28 CVEs.

What remains is practical: REPACK CONCURRENTLY for busy tables, smarter parallel autovacuum, and sequence synchronization for logical replication. Plan Advice, from PostgreSQL major contributor and committer Robert Haas, is the community's answer to Oracle-style optimizer hints it rejected for years. Somebody found a way of doing it that didn't have the downsides," Momjian said.

The database as AI's memory

The two diverge on how fast AI will write SQL. Momjian expects agents to create databases and generate much of the code. Stonebraker says that will not happen inside the enterprise until data is documented, silos are opened, and the politics change. They agree on the destination. AI needs a relational system to give it permanence and memory, and, in Momjian's words, that is a game-changer."

Forty years on, the inventor and the steward are betting on the same database.

Contributed by EnterpriseDB

External Content
Source RSS or Atom Feed
Feed Location http://www.theregister.co.uk/headlines.atom
Feed Title www.theregister.com - Articles
Feed Link https://www.theregister.com/
Reply 0 comments