Turing Award Winner: Postgres, Disagreeing with Google, Future Problems | Mike Stonebraker

Overview

Mike Stonebraker reviews the history from Ingres → commercial Ingres → Postgres, explains motivations and key architectural choices, and gives technical takes on databases, distributed systems, LLMs applied to SQL, and his recent research/startup project Deboss.

---

Historical / product highlights

Ingres → Postgres

• Ingres (early 1970s, Berkeley) implemented relational ideas from Ted Codd; written from scratch as a full DBMS.
• Postgres was designed to be extensible:
  • User-defined / abstract data types (e.g., GIS types: points, lines, polygons).
  • Custom date/time semantics to support domain-specific calendars (e.g., finance).
  • Inheritance and time travel (time travel was later removed).
  • Other extensibility features not present in Ingres.
• Postgres has become a “lowest common denominator” open-source relational DB — excellent for general use and the developer ecosystem, but not optimized for large-scale data warehouses (no native column-store or built-in multi-node warehouse architecture).

---

Technical analyses and critiques

Query optimizer

• The query optimizer is described as the hardest part of building a DBMS — algorithmically difficult and still the top technical challenge in DB engineering.

One-size-does-not-fit-all

• Specialized systems can be orders of magnitude faster than general-purpose DBs for specific workloads:
  • Stream processors (e.g., StreamBase research).
  • Column stores (e.g., Vertica, ClickHouse).
  • Vector/graph engines (e.g., Pinecone).
• Postgres is ideal for many uses, but specialized systems win at the high end (petabyte warehouses, million-TPS workloads).

MapReduce / Hadoop criticisms

• Hadoop/MapReduce are inefficient for many workloads compared to distributed DB approaches.
• Early advocacy of eventual consistency (at Google) was misguided for many enterprise applications where strong consistency and transactions are required; subsequent systems (Spanner) adopted conventional transactional models.

GPUs and indexing

• GPUs (SIMD) can help some workloads but conflict with indexing patterns:
  • B-tree pointer-chasing memory access does not parallelize well for SIMD.
  • Data transfer / bus bandwidth from storage to GPU can be a bottleneck.

Cloud providers / product proliferation

• Critique of cloud providers (e.g., Amazon) offering many overlapping DB products.
• Recommendation: prune offerings to a smaller set of well-maintained, high-value systems.

---

Deboss (research → startup)

Research idea

• Replace parts of an OS (upper layer) with a stateful DBMS; treat scheduling and other OS tasks as data-management problems.

Product features

• Language-level integrations: extensions/variants for TypeScript, Java, Go, Python so programs can treat state as persistent DB-backed state with transactional semantics.
• Workflow-first model:
  • Workflows are durable and transactional (per-step durability).
  • Workflows can be made atomic (commit whole workflow or it appears not to have happened).
• Target use cases: cloud workflows, large-scale orchestration, agentic AI (many customers use Deboss for agentic read-write scenarios).
• Selling points: simpler programming model, high availability, easier persistence, and transactional guarantees for multi-step workflows and agentic applications.

Market note

• VCs were skeptical about displacing Linux; Deboss started as a programming-language / DB-layer innovation and is commercializing workflow/transactional state use cases.

---

LLMs, text-to-SQL, and the Beaver benchmark

Benchmarks discussed

• Academic: Spider and BIRD (text-to-SQL benchmarks).
• Stonebraker’s real-world benchmark: Beaver (anonymized from four production data warehouses).

Findings

• SOTA LLMs perform reasonably on academic benchmarks (~80–85% on Spider/BIRD) but fail on real production data warehouses.
• On Beaver:
  • Direct text-to-SQL: ~0%.
  • With retrieval-augmented-generation (RAG) and tricks: ~10%.
  • If given FROM clause + joins: ~35%.

Reasons LLMs fail on real warehouses

• Training data mismatch: warehouse-specific schemas/data rarely appear in LLM pretraining corpora.
• Much higher query complexity: real queries are often many times longer and more complex than academic benchmarks.
• Messy, non-mnemonic schemas, materialized views, redundancy, and idiosyncratic data values (domain-specific terms).

Recommendations / best practices

1. Don’t expect LLMs alone to reliably generate production SQL for complex warehouses.
2. Use retrieval prompts that include concrete schema fragments: FROM clauses and join hints.
3. Break complex queries into simpler sub-queries.
4. For multi-source structured joins (warehouse + CRM + CAD + text), convert sources into structured tables and use SQL query optimization / planner to join — i.e., “turn everything into tables” and use DB tech for structured joins.
5. Expect agentic/read-write AI to create distributed DB problems (atomicity, consistency); these are not solved by current LLM-only approaches.

---

Practical guidance, tools, and references

Published resources

• Beaver benchmark: anonymized benchmark derived from real data warehouses for testing text-to-SQL systems.
• Recommended reading: Readings in Database Systems (the “Red Book”) by Joe Hellerstein & Mike Stonebraker — a curated set of important DB papers.

Hiring advice

• Identify top engineers via deep, precise technical questioning (thesis details, handling error conditions, process/thread design).
• Exceptional candidates are those who accomplish significantly more with similar inputs.

Career advice

• Pursue interesting, contrarian problems.
• Find strong mentors.
• Focus on impactful research or startups.

---

Peripheral / miscellaneous

• Host mentions building an ultra-low-profile ergonomic keyboard as a side project (prototype linked in the episode).

---

Main speakers / sources

• Mike Stonebraker — Turing Award winner, database systems pioneer (Ingres, Postgres, Vertica/column-store research, Deboss).
• Podcast host / interviewer — led the conversation and mentions side projects (keyboard).

Referenced people and projects (secondary)

• Gene Wong, Ted Codd, Larry Ellison / Oracle, Jeff Dean (Google/Spanner), Matei Zaharia (Databricks/Spark), Joe Hellerstein, David DeWitt.
• Technologies: ClickHouse, Vertica, Pinecone, Spanner, Hadoop/MapReduce, StreamBase.

---

Additional deliverables (available)

• Extracted technical recommendations for deploying LLMs over databases (prompt templates, retrieval content to include).
• One-page checklist for deciding whether to use Postgres vs. a specialized DB for a given workload.