Why Enterprise AI Keeps Failing at Basic Database Questions, and What That Means for Who Controls Your Data

Imagine asking a simple question about your own organization's data, something a new employee might ask in their first week, and getting a wrong answer every single time. Not most of the time. Every time. That is what happened when Michael Stonebraker, the Turing Award-winning MIT professor who invented Postgres at Berkeley in 1986, tested a leading AI approach against his own university's data warehouse.

The promise sounds almost too good to pass up. Text-to-SQL lets a business user type a plain-English question and get an answer pulled straight from a company's database, no coding required. Public benchmarks like Spider and BIRD report accuracy above 80 percent, numbers that have fueled a wave of enterprise AI sales pitches.

Stonebraker's team ran the same approach against MIT's actual warehouse, 1,400 tables covering students, faculty, buildings, and salaries, using real queries pulled from the university's own logs. The result: zero percent accuracy. Not 80. Not 40. Zero. Adding agentic AI, retrieval tools, and careful prompt engineering nudged that number into the teens. Spelling out every table and join term by hand got it into the 30s. Still, in Stonebraker's words, "not ready for prime time."

Why the gap? Real enterprise data is messy in ways public benchmarks never capture. There is no training data available because the warehouse sits behind MIT's firewall, invisible to the public internet that trained the models. The data itself is idiosyncratic, down to the fact that MIT buildings are numbered, not named. Years of use have left the schema cluttered with cryptic table names and overlapping views. And the real questions people ask are simply harder than the tidy ones used in benchmark tests. Stonebraker's team published its own benchmark, called Beaver, and reports that nobody has broken past the 30-percent range on it.

This is not a story about AI being bad at language. It is a story about AI being bad at something enterprises rely on constantly: joining structured data across tables, departments, and systems. Stonebraker puts it plainly: language models are "no good at doing joins of structured data," and that is most of what a typical enterprise actually holds.

Working with the city of Munich's transport department, his team found that answering a single citizen's complaint about crosswalk timing required combining traffic regulations, CAD drawings, trolley schedules, and school-zone maps. Trying to orchestrate all of that with a language model sitting at the center of the process was, Stonebraker said, "ridiculously expensive."

The Architecture Behind the Fix

His team's response is a system called Rubicon, which uses language models only for text, converts the results into structured tables, and then hands the rest of the work to a dedicated tabular engine. The orchestrator, he says, "looks like a query optimizer" rather than a chatbot. The payoff: roughly ten times cheaper and considerably more accurate than the agent-centered frameworks currently dominating the market.

That architectural choice carries a governance lesson. Stonebraker expects agentic AI to slide from hype into what he calls the valley of despair before expectations recalibrate. Enterprises, he notes, cannot tolerate non-determinism, the possibility that a system gives different answers to the same question on different days. Approve a loan one day and reverse the decision on review, and "that's called a lawsuit." Protecting against rogue agents matters just as much. The good news, he argues, is that the guardrails already exist inside the database layer: decades of access controls, complete audit logs, and triggers that can halt a transaction mid-stream. Rather than bolting AI on top of enterprise systems as an outside layer, Stonebraker suggests data-heavy agents belong inside the data layer itself, as functions the database runs directly, assuming the tooling to debug and version them keeps improving.

He is just as direct about the frontier models themselves. The internet's genuinely useful training data has largely been used already, and he knows of no enterprise willing to let outside models train on its proprietary records. Artificial general intelligence, in his assessment, is "basically marketing hype" that foundation model vendors use to justify sky-high valuations.

This is where the question of who controls the infrastructure becomes unavoidable. Bruce Momjian, cofounder of the PostgreSQL Global Development Group and a longtime contributor at EnterpriseDB, describes Postgres as "the intergalactic answer to open source." Its defining feature is not a technical one. It is that no single company controls it. EDB, Microsoft, Google, and other organizations all contribute committers, and no one entity steers the project. Stonebraker traces Postgres's rise directly to a moment of corporate consolidation: when Oracle bought MySQL, the industry's reaction was swift. "Everybody said: vendor control." For enterprises weighing where to run AI systems on sensitive data, that independence underpins what the industry now calls data sovereignty, the ability to keep control over how and where your own information is processed.

Momjian describes the project's structure from inside it. Postgres has no office, no corporate assets, and no legal entity, yet it produces "software better than billion-dollar companies." Its forecasting mechanism is simply the global community of contributors, who spot emerging needs early across China, Russia, and the United States. "We only need one person in the world to be supersmart," he said, "and that person to tell us what they think."

Both men describe a design philosophy that prizes flexibility over squeezing out the last few percent of raw speed. Stonebraker built Postgres to be extended from the start, which is why it has absorbed JSON support, full-text search, geographic data handling, and now AI capabilities without needing a ground-up rewrite. Momjian adds a second principle dating to the 1990s: lean on the operating system rather than trying to replace it, a choice that made Postgres a natural fit when cloud computing arrived decades later.

Momjian is openly skeptical of optimizations that buy only 5 or 10 percent in performance at the cost of flexibility, since a poorly tuned system can lose 40 percent instead. "If you take a Formula One car to the supermarket, there's no place for the groceries," he said. The project plans on timelines most commercial vendors cannot match. "We're looking at what would be the impact 5 years from now, 10 years from now."

PostgreSQL 19 puts that discipline on display. Several previewed features, including SQL property graph queries and tools for partition merging and splitting, were pulled from the release because reliability came first. AI-assisted code review is catching problems faster than before; the August 2026 patch release for PostgreSQL 18 addressed 28 separate CVEs. What made it into the new release is practical rather than flashy: REPACK CONCURRENTLY for busy tables under load, smarter parallel autovacuum processes, and sequence synchronization for logical replication. Plan Advice, developed by major contributor Robert Haas, answers a question the community wrestled with for years, how to offer Oracle-style optimizer hints without their downsides. "Somebody found a way of doing it that didn't have the downsides," Momjian said.

The two experts do disagree on timing. Momjian expects AI agents to start creating databases and generating much of their own code relatively soon. Stonebraker counters that this will not happen inside real enterprises until data gets properly documented, organizational silos open up, and the internal politics shift, changes that tend to move far slower than technology does.

Why It Matters

Where they agree matters more than where they diverge. AI systems need a relational database to give them permanence and memory, structured, auditable, and durable in a way that a chatbot's conversation history never is. For Momjian, that combination is simply "a game-changer." Forty years after Stonebraker first introduced Postgres at Berkeley, the system's inventor and one of its longest-serving stewards are betting on the same foundation, not because it is the fastest option available, but because it bends without breaking and answers to no single company's balance sheet.