Postgres Turns 40 : Extensibility, enterprise readiness, and the next life of data in the age of AI

In 2026, the PostgreSQL community celebrates 30 years of the project, but I call this keynote Postgres Turns 40 because the idea is older than the name. The Berkeley POSTGRES design work started in 1985, and the paper by Michael Stonebraker and Lawrence Rowe, “The Design of POSTGRES”, was published in 1986. For me, the important continuity is not a rename or a release date, but the idea of an extensible database that can accept new kinds of data and new kinds of work without losing trust. I joined the Postgres95 community when it was still small, and most of my life with Postgres has been connected with that same question. Extensibility was never only an architectural slogan for me. It was a practical way to bring non-traditional data into the relational world: languages beyond ASCII, full-text search, arrays, trees, similarity search, key-value attributes, semi-structured documents, and eventually jsonb and SQL/JSON. JSON is a good example of the larger story. What started as flexible, weakly structured data, often associated with document databases, became a first-class part of relational database systems. Postgres showed that new data does not have to live outside SQL, transactions, indexes, backup, access control, and operational discipline. The early POSTGRES papers already pointed in this direction: complex objects, extensible types, operators and access methods, active rules, historical data, versions, new hardware, and minimal changes to the relational model. Forty years later, some ideas survived directly, some changed form, and some returned at another level. Time travel is a good example: user-visible historical queries disappeared, but tuple versions and transaction identifiers became the foundation of MVCC. Today the same question becomes an enterprise question. New workloads are coming to the data that already live in Postgres: HTAP, fresh analytics close to writes, hybrid search, transaction SLA, and AI agents working with documents, logs, permissions, history, tool outputs, and task context. The next decade should make Postgres a real entry point for data work, not just a stable protocol or a trusted place to store transactional truth. This does not mean that every computation must run inside the PostgreSQL backend. External engines may participate in execution, but Postgres should remain the place where data identity, visibility, permissions, freshness, provenance, cost, and responsibility for the result are defined. For that, Postgres core must grow the mechanisms that new workloads need: derived representations, value representation, hybrid search, heterogeneous execution, governed integration with external engines, and an AI-assisted community infrastructure, where agents help developers find context, evidence, old discussions, tests, and consequences of changes, while human review and responsibility remain at the center.