Database Legend Mike Stonebraker: The Birth of Postgres and Challenges in the AI Era

Mike Stonebraker, a Turing‑Award‑winning database visionary, reflects on his career from a 1971 Berkeley graduate to the creator of Ingres and Postgres, highlighting the early dominance of Codasyl and IBM IMS, the appeal of Codd’s relational model, and the launch of Ingres in 1972 that earned him tenure in 1976 but later failed commercially due to a missing COBOL compiler for a large student‑record deployment.

From Ingres to Postgres

Stonebraker identifies Ingres’s inflexible type system as a fundamental flaw—its inability to support GIS data types and complex financial date calculations (e.g., a 30/360 rule) forced a redesign, leading to Postgres with an extensible type system, native support for custom data types, inheritance, and early time‑travel features (later removed).

Talent, Competition, and Industry Critique

He argues that outstanding engineers are evident when they produce three times the expected output, and that deep technical conversations quickly reveal competence. Stonebraker harshly criticizes Oracle’s premature feature promises, calls Hadoop’s efficiency “absurd,” and notes Google’s shift from eventual consistency in Spanner back to traditional transaction processing.

DebOS: Databases as Operating‑System Kernels

Inspired by Databricks’ need to schedule millions of Spark jobs, Stonebraker’s team built “DebOS,” replacing OS core services (file system, scheduler, process management) with DBMS components. Experiments showed DB‑based file systems outperform Linux native ones, the scheduler was competitive, and the system inherited high‑availability features. In 2023 they founded DebOS Inc., targeting cloud‑native applications with built‑in database capabilities via extensions for TypeScript, Java, Go, and Python, especially for stateful workflow and agentic AI workloads.

AI Era: Text‑to‑SQL Challenges

Stonebraker’s group evaluated Text‑to‑SQL on four real data‑warehouse workloads, finding that while large language models achieve ~85% accuracy on Spider/Bird benchmarks, they score 0% on the real warehouses (10% with RAG, ~35% when tables and join conditions are supplied). He attributes the gap to training data mismatch, query complexity (10‑20 lines vs. up to 100 lines), and opaque schema names, noting that a skilled SQL user can exceed 90% accuracy.

Future Direction

He proposes converting all data sources into tabular form and leveraging query optimizers for joins, exemplified by a collaboration with Munich’s transport authority that integrates SQL timetables, CAD road‑network data, and regulatory texts.

Advice for the Next Generation

Stonebraker urges young professionals to think wildly, pursue passion over trends, choose stable sectors like healthcare or construction, seek prestigious mentors, and focus on deep expertise rather than following the crowd, emphasizing that fulfillment outweighs financial gain.