Do Databases Have a Future? | Conversations in Action

Overview

• Speaker: John Werner, Dr. Alex Wissner-Gross, and Michael Stonebraker
• Channel: Imagination in Action
• Main topic: The future of databases, relational models, foundational models, LLMs, and enterprise data architecture
• Purpose: Analyze the long-term viability of relational databases in the age of LLMs and AI agents, examining data structure fundamentals, enterprise data challenges, and software architecture evolution. A deep technical conversation featuring Turing Award winner Michael Stonebraker, Dr. Alex Wissner-Gross, and John Werner discussing whether large language models and foundation models threaten the dominance of relational databases, why schema rot and data silos persist in enterprises, the limits of unstructured text in AI, and the historical lessons of database versus operating system design.

Topic Map

Introduction and Panel Setup

• Explanation: John Werner introduces Dr. Alex Wissner-Gross and guest Michael Stonebraker, Turing Award winner and database pioneer.
• Key claims:
  • Michael Stonebraker is a Turing Award winner and founder of multiple successful database companies.
  • Stonebraker is often viewed as a living founding father of modern database systems.
• Examples:
  • Ingres, Postgres, Vertica, SciDB, and C-Store founding history.
• Terminology:
  • Turing Award
  • relational database
  • founder
• Why it matters: Establishes the pedigree of the guest and sets the stage for a foundational discussion on data systems.

LLMs and Foundation Models vs Relational Databases

• Explanation: Alex Wissner-Gross asks whether LLMs and foundation models represent the first true exception to all alternative data structures collapsing into relational databases.
• Key claims:
  • Essentially all data sources feeding agentic AI are relational underneath.
  • Treating data as raw text and performing joins via text-to-text generation throws away valuable structural information.
  • Foundation models are text-to-text only and lack rigorous structural query guarantees.
• Examples:
  • Comparing programmatic joins on relational tables vs text-based stitching in LLMs.
• Terminology:
  • relational model
  • LLM
  • foundation model
  • compressed knowledge
  • schema rot
• Why it matters: Addresses the existential question of whether vector databases and LLMs replace traditional structured database management.

Enterprise Data Silos and Schema Rot

• Explanation: Discussion of why enterprise databases suffer from schema rot and how real-world data integration remains difficult.
• Key claims:
  • Data warehouses are never in the public domain and always behind strict firewalls.
  • Over time, overlapping semantics create schema rot in nearly all legacy warehouses.
  • Enterprise workflows are full of edge cases, disparate sources, and non-mnemonic column names.
• Examples:
  • MIT data warehouse column naming conventions vs Spider and Bird benchmark datasets.
• Terminology:
  • schema rot
  • data warehouse
  • semantic overlap
  • multitable join
• Why it matters: Explains why AI models struggle with enterprise data tasks due to messy underlying corporate data structures.

Database Architecture vs Operating Systems: DBOS

• Explanation: Michael Stonebraker discusses DBOS, a project arguing that operating systems should be built as applications running on top of databases.
• Key claims:
  • Cloud infrastructure has outgrown 33-year-old Linux paradigms.
  • DBOS treats the operating system as an application running on a database, enabling durable workflows and transactional safety.
  • Venture capitalists backed DBOS on the premise that cloud-native architectures require database-backed primitives.
• Examples:
  • Building scalable schedulers and state management with transactional ACID guarantees.
• Terminology:
  • DBOS
  • operating system
  • ACID
  • transaction
  • durable workflow
• Why it matters: Demonstrates ongoing radical innovation in database systems research applied to core infrastructure.

Open Source vs Proprietary Software in Databases

• Explanation: Historical perspective on how open-source databases like PostgreSQL defeated proprietary vendors like Oracle.
• Key claims:
  • PostgreSQL and Linux succeeded because they became open-source public domain goods owned by no single entity.
  • Oracle bought MySQL and acquired MySQL/SQL assets, causing developer communities to flee toward PostgreSQL.
  • Open-source data structures offer immense advantages over closed-source corporate lock-in.
• Examples:
  • Postgres history, UC Berkeley origins, and Oracle acquisition fallout.
• Terminology:
  • PostgreSQL
  • Oracle
  • open source
  • proprietary
  • licensing
• Why it matters: Provides insight into long-term commercial and architectural sustainability of enterprise software.

Graph Databases vs Relational Databases

• Explanation: Evaluation of graph databases and whether graph models offer fundamental advantages over relational tables.
• Key claims:
  • Graph databases model data as edge tables and node tables, which are fundamentally relational.
  • When running queries finding the shortest path, tabular relational systems often outperform native graph implementations if properly indexed.
  • Most proposed data structures over the last 17 years (including graph databases) fail to provide fundamental advantages over relational databases.
• Examples:
  • Neo4j vs relational table performance on graph traversal workloads.
• Terminology:
  • graph database
  • node table
  • edge table
  • shortest path
  • Neo4j
• Why it matters: Defends the enduring optimality of the relational model against specialized database fads.

Key Points

Relational Models Remain Foundational for AI

• Explanation: All major data sources feeding advanced AI agents are relational underneath; ignoring structure in favor of pure text processing is inefficient.
• Evidence: Stonebraker argues that text-to-text joining throws away explicit structural constraints.
• Practical implication: AI agents operating on enterprise data need structured relational interfaces rather than flat text embeddings alone.

Enterprise Data Suffer from Severe Schema Rot

• Explanation: Real-world corporate databases accumulate conflicting semantics, non-mnemonic identifiers, and data silos over decades.
• Evidence: Enterprise data warehouses require complex multi-way joins across messy, uncurated schemas.
• Practical implication: Fine-tuning models on public benchmarks does not prepare them for messy enterprise data environments.

Open Source Dominates Infrastructure Software

• Explanation: Projects like PostgreSQL and Linux succeeded by remaining community-owned and unencumbered by corporate monopoly.
• Evidence: PostgreSQL became the world's most used database after Oracle's commercial maneuvers drove developers away.
• Practical implication: Infrastructure developers should prioritize open ecosystems to ensure developer adoption and longevity.

Graph Databases are Tabular Under the Hood

• Explanation: Graph databases are conceptually equivalent to edge and node tables in a relational database.
• Evidence: Queries on graph databases can be expressed as relational table joins.
• Practical implication: Do not adopt specialized graph engines without evaluating whether relational systems with proper indexing suffice.

Frameworks, Models & Processes

DBOS (Database Operating System)

• How it works: Replaces traditional OS state management with transactional database primitives, ensuring durable workflows and crash recovery.
• Components:
  • Transactional database core
  • Durable workflow engine
  • State management layer
• When to use: Cloud-native application infrastructure requiring high reliability and state persistence.

Relational Data Modeling

• How it works: Organizes data into tables of rows and columns, enforcing atomicity, consistency, isolation, and durability (ACID).
• Components:
  • Tables
  • Primary keys
  • Foreign keys
  • Joins
• When to use: Structured enterprise data storage, transactional processing, and complex querying.

Examples & Case Studies

Municipal transportation department in Munich using Postgres/Ingres-derived tech for trolley scheduling.

• Illustrates: Real-world application of agentic and database systems handling ambiguous human complaints and transit schedules.
• Lesson: Handling real-world operational edge cases requires rigorous data structures beyond simple prompt responses.

Oracle acquiring MySQL and subsequently driving open-source developers to PostgreSQL.

• Illustrates: The risk of proprietary ownership in open infrastructure software.
• Lesson: Community-governed open-source software outlasts corporate proprietary control in foundational technology.

Actionable Takeaways

• Immediate:
  • Recognize that graph databases are fundamentally relational table representations.
  • Understand that LLMs and foundation models process text rather than structured database schemas natively.
• Strategic:
  • Prioritize open-source relational foundations like PostgreSQL for enterprise data architectures.
  • Anticipate the evolution of cloud operating systems toward database-backed primitives like DBOS.
• Questions to investigate:
  • How will text-to-SQL agents handle enterprise schema rot at scale?
  • Can database-backed operating systems replace legacy Linux kernel architectures in production?

Claims Worth Verifying

• PostgreSQL is the most used database on the planet. (market statistic)
• Graph databases are equivalent to node and edge tables. (technical architecture)
• DBOS treats the operating system as an application running on a database. (system design)

Notable Quotes

"Everyone I know is building agents. You've said today's agents are mostly read only. What breaks first when agents start writing to the world?" (at 0:13) "Well, if you ask me that question, I would say, well, health care and the building trades seem safe. Everything else seems to be a risk." (at 0:24) "My take is you should learn Chinese because I think we are like post-World War II Britain." (at 0:32) "Mike Stonebreaker is the closest thing software has to a living founding father." (at 2:29) "I'm not sure I'd recommend an 18 year old study computer science." (at 3:31) "You've spent decades talking about how every other model other than the relational model is being dissolved in some sense by relational." (at 5:03) "The fundamental data structure is simply compressed knowledge and it's usually end-to-end differentiable, but looks nothing like a relational model." (at 5:37) "If you generalize that slightly to agentic AI, then then essentially all the all the data sources are relational that feed agentic AI." (at 6:41) "They will get turned into text and you will do the join as a text." (at 7:27) "That throws away structure, which is clearly a terrible idea." (at 7:34) "If you want to join table to text, in my opinion, you're better off converting the text to or the document to a table and doing a table to table joint." (at 8:36) "One of their big flaws is that they are text text only." (at 8:59) "Mike, you launched DBOS 36 months ago with Mata Zaharia and raised $8.5 million on the argument that the cloud has outgrown three year old Linux." (at 55:26) "I think the quid keyboard is going to be with us through the heat death of the universe." (at 116:41)

Compressed Summary

• Relational database structures remain superior to graph databases and text-based LLM architectures for structured data operations.
• Enterprise data suffers from widespread schema rot and semantic overlap, posing a major challenge for AI agents.
• PostgreSQL succeeded as an open-source standard by remaining independent of corporate monopoly.
• DBOS represents a paradigm shift treating operating systems as applications built on databases.
• Keywords: databases, relational, ai, opensource, architecture
• Core insight: Despite the rise of LLMs and alternative data structures, the relational model remains the foundational bedrock of computing and AI data pipelines.