Turing Winner Stonebraker: Why LLMs Won't Replace Relational Databases & AI Agent Pitfalls

LLMs and the Relational Model

Stonebraker maintains his long-held conviction that all data models will eventually be absorbed by the relational model. He argues that every data source feeding an AI agent is fundamentally relational. Traditional agentic AI systems convert structured sources to text for text-to-text joins, losing structure. The better approach is to keep tables as tables and join table-to-table, or convert documents into tables first. Foundation models' text-only processing is a fundamental weakness.

He illustrates with a Munich crosswalk-complaint project: four staff handle citizen complaints about short green-light durations. Resolving a complaint requires joining traffic regulations (text), CAD intersection drawings (structured), tram timetables (structured), map data for geocoding, and school-timing signal adjustments (structured). Traditional agentic AI failed completely because it could not handle the mix of text and structured data with multi-table joins.

Why Text-to-SQL Still Falls Short

Stonebraker identifies four reasons Text-to-SQL remains far from production-ready:

Training data isolation: Enterprise data warehouses sit behind firewalls; LLMs never see them. A query like "Which department is Mike Stonebraker in?" has no answer unless public news mentions it.

Schema corruption: Real warehouses (e.g., MIT's) contain non-standard names like _XYZ, overlapping semantics, and materialized views. Stonebraker calls this "schema corruption." Public benchmarks (Spider, BIRD) use clean schemas (employee, department, salary) that bear no resemblance.

Domain-specific concepts: MIT's "J-term" (January teaching month) appears nowhere else; an LLM cannot answer J-term questions.

Complex join depth: Real warehouses routinely require 4-5 table joins, far exceeding benchmark queries.

He adds that even if compute became cheap enough to train on the full internal warehouse, generating a usable data dictionary with business semantics and full lineage for derived columns is "probably never" achievable at MIT.

Can AI Understand Enterprise Data?

Stonebraker is skeptical. You cannot throw the text of a 4-table join at an agent and expect an answer. Only organizations with clean schemas and elite AI teams (like Google) might succeed. In practice, ~20% of enterprise AI pilots reach production; adoption faces huge resistance. Two overlooked blockers: (1) few enterprises will send proprietary data to OpenAI, forcing local open-source models; (2) access control (e.g., salary data in MIT's warehouse) must be enforced for any model.

DBOS: Rethinking Cloud with a Database-Centric OS

DBOS (co-founded with Matei Zaharia) puts all critical OS state under a database management system. State becomes recoverable; scalable schedulers and fault tolerance become simpler. The insight: generative AI workloads are long-running, compute-intensive graph workflows with loops. They need persistent workflows — after each step, state is saved; on failure, restart from the last successful step (ACID durability). DBOS reuses the database's transaction implementation for exactly this, targeting agentic AI as the primary use case.

When AI Agents Execute Write Operations

Current agents are mostly read-only. Write operations introduce classic database problems:

Compensating rollbacks (Saga): If a salary-increase transaction commits, then a later step decides the raise was too high, you must roll back the committed transaction. If another user modified the salary in between, you need a compensating transaction, not a physical erase. The database field solved this in the 1980s with the Saga pattern.

Isolation: Once a business process spans multiple transactions, isolation is lost unless you wrap everything in one giant transaction (impractical).

Atomicity: A bike-purchase workflow (inventory check → credit check → payment → shipping) must appear atomic. Each step is a separate transaction; failures require compensating actions (cancel payment, restock inventory). Achieving workflow atomicity is hard.

Career and Historical Reflections

Stonebraker entered CS pragmatically: high math SAT, low verbal SAT, father an EE, and graduate school avoided the Vietnam draft. He realized computers would change the world by junior year, mainly as a career bet.

Oracle vs. Ingres

Oracle founded a year earlier. By 1984 Ingres was growing faster, but IBM's SQL-based DB2 and Oracle's native SQL support ended QUEL's era. Ingres added SQL in 12 months, but Oracle had already pulled ahead. Stonebraker also cites Oracle's deceptive marketing: documenting referential integrity with a footnote "not yet implemented," blurring shipped vs. future features.

PostgreSQL's Success

Open-sourcing Ingres was Stonebraker's personal tenure-track decision, not Berkeley policy. Two students added SQL; a volunteer community (unconnected to Berkeley) maintained it for 30 years. The core committee (~20 members) includes Microsoft, EDB, Google — yet no single company owns Postgres. Oracle's acquisition of MySQL drove developers to Postgres. Stonebraker hopes open-source foundation models (e.g., DeepSeek) will eventually win on cost per useful token, as accuracy gaps narrow to a few percentage points.

Database-Based OS: Lessons from Longhorn

Microsoft's Longhorn (Vista) tried to build Windows on an object-relational database but failed due to scope creep and mismanagement, not the core idea. DBOS initially aimed to replace the Linux kernel with a relational database, but VCs noted a 10-year adoption cycle plus the driver ecosystem. A safer path would have been an enhanced Linux that swaps core modules while keeping the Linux ABI — a route DBOS did not take.

Claude and Software Development

Stonebraker praises Claude's ability to discard and rewrite whole modules, making large-scale refactoring (e.g., Linux kernel in Rust, Postgres in Rust) feasible. He suggests enterprises adopt incremental, module-by-module replacement of legacy code using this capability — a strategy impossible three years ago.

AI and Technical Debt

Every enterprise drags a "boulder" of legacy code, much of it COBOL with no maintainers. Acquisitions create data silos; 95% of IT budgets go to maintenance. Agentic AI could integrate systems upfront and gradually eliminate existing silos instead of adding new ones. Stonebraker's highest hope: legacy code ceases to be a massive obstacle.

Graph Databases Have No Future

Stonebraker and Andy Pavlo's 2008 paper "What Goes Around Comes Around" argued pre-2008 specialized models were flawed. Their 2025 follow-up extends the critique to the last 17 years, including graph databases. A graph maps to an edge table + node table; relational execution on that schema often outperforms native graph engines (Neo4j performance is poor). Amazon's graph database uses the relational-table approach underneath. The only plausible graph use case is shortest-path queries, but those belong in main-memory with specialized algorithms — two orders of magnitude faster — not in a database system. Stonebraker has yet to see a genuine graph-database sweet spot.

Turing Award Critique

Stonebraker believes 1979 winner Charlie Bachman was undeserving; the committee was skewed toward programming-language researchers. He sees the award as increasingly political, though still prestigious. Early winners (Knuth, Minsky) were clear; today's expanded field makes selection harder.

AI, China, and the West

Stonebraker states the U.S. is being overtaken by China, accelerating now. He advises learning Chinese for a world no longer Western-led. An 18-year-old today has a high probability of working for a Chinese company in 15 years. Evidence: China's 40 top universities, 10× population, and SIGMOD paper share shifting from 80% U.S. (20 years ago) to ~66% Asia last year. The interviewer counters that AI translation may obviate language learning and that AI-written papers will dominate in 15 years. Stonebraker replies that progress has come from a small elite; if that elite becomes irrelevant, we live in a machine-controlled world — a world he is glad he won't see.