Video summary

The Database That Should Be Dead but Runs the Internet

Main summary

Key takeaways

Technology

Core technological story / analysis

  • Relational model foundation (IBM, 1970): Edgar F. Codd publishes the relational model, organizing data into tables/rows/relationships with mathematical query precision.
  • Ingres proves relational works in practice (1970s–1980s): Michael Stonebraker and Eugene Wong implement the theory as Ingres, showing relational databases could be built and perform well enough to be useful.
  • Postgres redesign (1980s–early 1990s): Stonebraker moves toward a “complete rewrite” called Postgres, shifting focus from business-only data structures to a database meant to handle more kinds of data, enabled by:
    • Extensibility: custom data types, custom index methods, custom query operators
    • A platform mindset (grow with computing), funded partly by DARPA / ARO / NSF / defense-related sources
  • Postgres’ “correct over fast” challenge during “database wars”: The 1980s emphasis on performance makes Stonebraker’s extensible/correct design harder to sell as a commercial argument.

Key product/feature milestones

  • Late 1980s/1992: Berkeley ships Postgres 4.2 (final Berkeley release).
  • SQL compatibility problem (mid-1990s):
    • PostgreSQL initially uses Quel, a query language not widely adopted outside Berkeley.
    • Two Berkeley PhD students, Andrew Yu and Jolly Chen, add SQL support themselves, resulting in “Postgres95.”
  • Open-source transition via volunteer maintainers (1995–1999):
    • The project reaches users through non-university/community channels (donated server/independent hosting and mailing lists).
    • Major volunteer contributions include:
      • Query optimizer work (Tom Lane): focuses on correctness issues and the part of the system most likely to silently produce wrong results.
      • MVCC (Multi-Version Concurrency Control) (Vada Makeev): enables readers/writers to avoid blocking each other.
    • PostgreSQL 6.5 (June 1999) ships with MVCC, presented as a key stabilization milestone and a defining “feel” feature.
  • Document + relational unification (2012 onward):
    • 2009–2012 NoSQL pressure: JSON support debates occur on the mailing list.
    • PostgreSQL 9.2 (2012) adds native JSON support.
    • Follow-up: JSONB provides document flexibility while keeping relational guarantees and extensibility principles.
  • AI-era extensibility (2021–2023):
    • PGVector extension (Andrew Kane, April 2021) adds vector data types + similarity search, enabling modern vector/embedding retrieval.
    • Postgres ecosystem impact: vector databases surge after ChatGPT; Postgres already had free vector support, helping adoption.

Adoption, ecosystem, and “managed Postgres” effects

  • Enterprise/cloud recognition:
    • 2010 EU antitrust review names PostgreSQL as a credible alternative constraining Oracle’s power (i.e., treated as “load-bearing” infrastructure).
    • Apple OS X Lion Server (2011 era) ships PostgreSQL instead of MySQL (implying internal engineering validation).
  • Managed PostgreSQL services (mid-2020s):
    • Big cloud providers offer managed Postgres (e.g., Amazon RDS, Google Cloud SQL, Azure Database for PostgreSQL).
    • Other open-source projects responded with license changes; Postgres kept a permissive license, which is framed as a key reason it avoided the “extraction without contribution” cycle.
    • Result: cloud providers and ecosystem companies develop a stake in maintenance, including funding/hiring maintainers rather than only monetizing usage.

Review/guide/tutorial mentions

  • No explicit “review” of a product like a buying guide or tutorial steps. The content is primarily historical/technical analysis of database design choices and community/process dynamics.

Key “how it survived” claims (technology + governance)

  • Open-source maintenance model: PostgreSQL survives without a single owner because funding is fragmented among competing sponsors, keeping governance neutral.
  • Extensibility as an architectural strategy: The original Postgres extensibility design enables:
    • SQL compatibility adaptation (earlier)
    • JSON/JSONB feature growth
    • AI vector search (PGVector)
  • Community contributions as long-lived infrastructure: Many maintainers continue across decades; the project “works” because patches and reviews keep flowing through the same mailing-list workflow.

Main speakers / sources mentioned (by name)

  • Edgar F. Codd (IBM; relational model paper)
  • Michael Stonebraker (Ingres/Postgres; later industry work)
  • Eugene Wong (Ingres)
  • Andrew Yu (added SQL support; Postgres95)
  • Jolly Chen (added SQL support; Postgres95)
  • Tom Lane (query optimizer; MVCC-era volunteer maintainer)
  • Vada Makeev (MVCC contribution; shipped as part of PostgreSQL 6.5)
  • Andrew Kane (PGVector extension)
  • Alexander Korotkov (OrioleDB storage engine; Postgres committer mentioned)
  • Mark Fournier (Canadian hosting/ran hub.org; offered first non-university server)
  • Bruce Momjian (Philadelphia consultant; patches/maintainer via mailing list)

Original video