Turing Award Winner: AI Scores Zero on Real Database Tests

The 83-Year-Old Database Pioneer Who Refuses to Follow the Hype

Mike Stonebraker, the 83-year-old Turing Award winner and founding father of PostgreSQL, has unleashed a series of blunt critiques targeting some of Silicon Valley's most sacred cows. In a wide-ranging podcast interview with Ryan Peterman, Stonebraker declared that today's hottest Text-to-SQL AI systems scored a flat 0 on real production database benchmarks, called Hadoop and MapReduce 'a dumb thing Google did,' and took aim at Oracle's decades-old sales playbook.

The conversation amounts to what some commentators are calling a 'Silicon Valley madman's diary' — a fearless, unfiltered assessment from someone who has spent 5 decades building the systems that power the modern data world.

Key Takeaways

• Text-to-SQL AI scores 0 when tested against 4 real production data warehouses, despite impressive results on academic benchmarks
• Stonebraker calls Hadoop and MapReduce 'one of the dumb things Google did'
• Oracle's early dominance came from aggressive sales tactics rather than technical superiority
• PostgreSQL's extensible type system was a deliberate architectural decision, not an accident
• Query optimizers remain the hardest unsolved problem in database engineering today
• The computer science field may no longer be a 'sunrise industry,' according to Stonebraker

AI's Text-to-SQL Promise Crashes Into Reality

The most explosive claim from Stonebraker's interview concerns the current AI hype around natural language to SQL conversion. Large language models like GPT-4, Claude, and Gemini have shown impressive abilities to translate plain English questions into SQL queries on standard benchmarks. Companies across the industry are racing to build products around this capability, promising that business users will soon query databases using everyday language.

Stonebraker's team put these claims to the test — and the results were devastating. They took 4 real production-grade data warehouses and ran today's leading Text-to-SQL systems against them. The score? Zero.

Not low. Not disappointing. Zero.

The gap between academic benchmarks and production reality exposes a fundamental problem. Academic datasets like Spider and BIRD use clean, well-documented schemas with straightforward naming conventions. Real enterprise databases look nothing like that. They contain cryptic column names, undocumented relationships, legacy table structures spanning decades, and business logic that no AI model can infer from schema alone.

This finding challenges the narrative that LLMs are about to democratize data access. While the technology may eventually mature, Stonebraker's benchmark suggests the industry is significantly overpromising on current capabilities.

Stonebraker Calls Hadoop 'A Dumb Thing Google Did'

Few figures in tech history would dare to call one of Google's most influential contributions to computing 'dumb.' Stonebraker does so without hesitation.

Hadoop and MapReduce, which Google introduced in landmark papers in 2003 and 2004, sparked a revolution in distributed computing. They gave birth to an entire ecosystem — Cloudera, Hortonworks, and countless startups built their businesses on the premise that MapReduce was the future of data processing. At its peak, the Hadoop market was valued at over $20 billion.

Stonebraker's argument is rooted in database fundamentals. MapReduce, he contends, essentially reinvented a worse version of parallel database technology that already existed. It lacked query optimization, schema enforcement, and the decades of performance engineering that relational databases had accumulated.

• MapReduce forced developers to write low-level code for operations that SQL handled declaratively
• Parallel databases from companies like Teradata and Vertica already solved distributed query processing
• The Hadoop ecosystem required enormous engineering effort to reach capabilities that databases offered out of the box
• Spark eventually replaced MapReduce's core processing model, implicitly acknowledging its limitations

History has largely validated Stonebraker's position. Cloudera and Hortonworks merged in 2019 amid declining relevance, and most organizations have migrated to cloud-native data warehouses like Snowflake, Databricks, and BigQuery — systems that look a lot more like traditional databases than like Hadoop.

Oracle's Rise: Sales Over Substance

Stonebraker's critique of Oracle reaches back to the earliest days of the relational database industry. In the 1970s, Stonebraker was building Ingres at UC Berkeley — one of the first relational database systems, alongside IBM's System R project. Oracle, founded by Larry Ellison in 1977, would go on to dominate the commercial market.

According to Stonebraker, Oracle's ascent had less to do with technical innovation and more to do with aggressive commercial strategy. While academics like Stonebraker focused on correctness, performance, and advancing the state of the art, Oracle focused on getting products to market and closing deals.

This is not merely sour grapes from a losing competitor. Stonebraker went on to build PostgreSQL, which today powers a massive share of the world's databases and serves as the foundation for products from Amazon Aurora to Supabase to Neon. His track record gives his critique real weight.

The broader lesson Stonebraker draws is about the tension between engineering excellence and commercial success — a tension that continues to shape the database industry today.

PostgreSQL's Secret Weapon: Extensibility by Design

One might expect Stonebraker to champion PostgreSQL as the universal answer to every database problem. He does not. Even as the system he created in the 1980s has become one of the most popular databases on Earth — Stack Overflow's 2023 developer survey ranked it as the most admired database — Stonebraker resists the temptation to declare it a one-size-fits-all solution.

What he does emphasize is the deliberate architectural decision that made PostgreSQL different: its extensible type system. Unlike other databases that shipped with a fixed set of data types, PostgreSQL was designed from the ground up to let users define new types, operators, and index methods.

• This extensibility enabled PostGIS for geospatial data, making PostgreSQL the default database for mapping applications
• It allowed pgvector to add vector similarity search, positioning PostgreSQL as a viable vector database for AI applications
• It supports custom data types for time-series, JSON, and domain-specific structures
• It gave PostgreSQL the flexibility to remain relevant across 4 decades of changing requirements

But Stonebraker cautions against treating any single system as the answer to everything. Specialized workloads — real-time analytics, graph queries, extreme-scale time-series — often benefit from purpose-built engines rather than a general-purpose database stretched beyond its design parameters.

The Query Optimizer: Database Engineering's Hardest Problem

Among the technical topics Stonebraker discussed, one stands out for its enduring difficulty: query optimization. This is the component of a database that decides how to execute a SQL query — which indexes to use, what order to join tables, whether to scan sequentially or seek by index.

Stonebraker considers query optimization the 'hardest bone to chew' in database engineering, even after 50 years of research. The problem is fundamentally combinatorial: for a query joining 10 tables, there can be millions of possible execution plans. The optimizer must choose a good one in milliseconds.

Modern optimizers use cost models, statistics, and heuristics to navigate this space. But they frequently make mistakes, especially on complex queries with correlated subqueries, skewed data distributions, or stale statistics. Every major database vendor — from Oracle to Microsoft to the PostgreSQL community — continues to invest heavily in optimizer improvements.

This is also where the AI conversation gets interesting. Could machine learning improve query optimization? Several research projects, including Bao (built in Stonebraker's own lab at MIT) and Google's work on learned indexes, suggest the answer is yes — but practical deployment remains limited.

Is Computer Science Still a 'Sunrise Industry'?

Perhaps Stonebraker's most provocative observation goes beyond databases entirely. He questions whether computer science itself remains a 'sunrise industry' — a field of expanding opportunity and growth.

This might seem counterintuitive at a time when AI is generating unprecedented investment. Nvidia's market capitalization has surpassed $3 trillion. Venture capital funding for AI startups exceeded $90 billion in 2024. Every major tech company is reorganizing around AI capabilities.

But Stonebraker's concern may reflect a different reality on the ground:

• Traditional software engineering roles are being automated by AI coding assistants like GitHub Copilot and Cursor
• Entry-level programming positions face compression as AI handles routine coding tasks
• The database industry itself is consolidating, with cloud providers absorbing functionality that once sustained independent companies
• Academic computer science departments face questions about what to teach when AI can generate code

Stonebraker is not predicting the death of computing. Rather, he is suggesting that the nature of the opportunity is shifting — and that the industry should be honest about that shift rather than papering over it with hype.

What This Means for Developers and Businesses

Stonebraker's critiques carry practical implications for anyone building on modern data infrastructure. For developers evaluating Text-to-SQL tools, the message is clear: test against your actual production schemas, not demo datasets. The gap between benchmark performance and real-world accuracy may be enormous.

For businesses considering AI-powered data access tools, the takeaway is to maintain realistic expectations. Natural language interfaces to databases may eventually work, but today's solutions likely require significant customization, schema documentation, and human oversight.

For the database community, Stonebraker's comments reinforce that fundamental engineering problems — query optimization, data modeling, system architecture — remain as important as ever. The AI wave does not make these challenges obsolete; if anything, it adds new layers of complexity.

Looking Ahead: Where Databases and AI Converge

Stonebraker's skepticism about current AI capabilities should not be mistaken for dismissal of AI's potential. His own research at MIT continues to explore the intersection of machine learning and database systems. The question is not whether AI will transform databases, but when and how.

The most promising near-term applications may not be the flashy ones. Rather than replacing SQL with natural language, AI might improve query optimization, automatic indexing, anomaly detection in data pipelines, and schema evolution management. These are unglamorous problems, but they represent billions of dollars in enterprise value.

At 83, Mike Stonebraker remains one of the sharpest and most uncompromising voices in computing. His willingness to challenge consensus — whether it comes from Google, Oracle, or the AI industry — is a reminder that progress in technology requires honest assessment, not just enthusiasm. In a world drowning in hype cycles, that perspective is more valuable than ever.