POSTGRES at Berkeley: Researching Extensible Database Systems

POSTGRES began as a University of California, Berkeley research project in 1986, led by Michael Stonebraker and a changing group of graduate students and staff. It followed Berkeley’s INGRES project, but it was not simply the same database with a new name. The POSTGRES design paper proposed a new system for exploring database features that were difficult to express cleanly in the relational systems of the day, including richer types, complex objects, rules, and support for evolving data.

The project is the ancestor of today’s PostgreSQL, but the names should not be collapsed across decades. Early POSTGRES was a research database, initially associated with the POSTQUEL query language and an experimental architecture. PostgreSQL came through later transformations, including a SQL-oriented release known as Postgres95. The current product inherits ideas and code lineage from Berkeley, but its present identity and implementation are the result of sustained work by a much broader community.

The research question after INGRES

Berkeley’s database group had already built INGRES, a relational system that demonstrated how database research could produce both academic results and practical software. By the mid-1980s, the group wanted to investigate what database systems might need beyond storing rows in conventional tables. Scientific, engineering, and business applications increasingly manipulated data structures such as images, geographic objects, design records, and time-dependent observations. A database that treated every value as a simple scalar could force applications to place too much logic outside the database engine.

The 1986 paper The Design of POSTGRES described a proposed successor to INGRES and framed extensibility as a central goal. “Postgres” was not a claim that the relational model itself had ended. The project experimented with how a database could accommodate new data types, operations, rules, and storage mechanisms while keeping data management inside a system that could query and recover them.

This distinction is important when comparing POSTGRES with System R or the later SQL standard. The relevant comparison is not whether one project “won” a contest to invent SQL. It is how researchers explored alternative data models and database extensibility, and how practical experience later shaped the product lineage. The Berkeley project was one thread in a larger history of database research.

Extensible types moved domain logic closer to data

One idea in the POSTGRES line was to allow users to define types and operations suited to their domains. A geographic application, for example, might need spatial values and operators such as overlap or containment. An engineering system might need structured design objects. A database with user-defined types can store and index such values according to defined semantics rather than treating everything as opaque text.

That extensibility creates a difficult systems obligation. The engine must have a safe and consistent interface for type definitions, input and output, comparisons, operators, and indexes. Query planning must know enough about costs and semantics to choose sensible execution strategies. Storage must preserve values and support recovery. An extension point is useful only when the surrounding system can reason about it without silently violating correctness.

The research concept of abstract data types was not unique to POSTGRES, and the project should not be credited with inventing every later extensibility feature. Its significance lies in making extensible database design a core part of an implemented system and testing the idea with real applications. The PostgreSQL project’s historical documentation describes the original system as the foundation from which today’s object-relational database was derived.

Rules and active database ideas

POSTGRES also explored rules as a way to describe how data should be transformed or how derived views should behave. A rule system can express relationships between stored facts and actions that follow when those facts change. This research touched questions still recognizable in triggers, views, and event-driven data processing: what should be recomputed, when should a rule fire, and how does the system prevent recursive or contradictory behavior?

Rules are not simply stored procedures under another name. A rule system can rewrite or expand queries based on declared relationships, while a procedure is generally invoked as a control-flow unit by an application or database call. The exact POSTGRES semantics evolved and were the subject of research. Present-day PostgreSQL rules and triggers are not direct evidence that every early behavior survived unchanged.

The early design’s interest in historical or time-varying data likewise should be framed as a research direction, not a claim that POSTGRES was a complete modern temporal database. The useful historical point is that the system challenged the assumption that a database merely stores static tuples and executes a fixed query language. It considered richer behavior as part of database architecture.

Storage and recovery were part of the experiment

Extensible data structures require a storage manager that can accommodate varying representations and operations. The POSTGRES research program examined how to manage objects, versions, and indexes without restricting the system to one fixed set of application schemas. A database design is not complete once a language can describe a new type; its storage, query execution, concurrency, and recovery machinery must still operate correctly.

The project’s sequence of papers reflects this decomposition. The official PostgreSQL history points readers to the design of the POSTGRES data model, rules system, and storage system, along with the general design paper. Those documents are valuable because they let a reader separate aspirational architecture from implementation results. Later histories compress this into a slogan such as “object-relational,” but the primary papers reveal the engineering decisions behind the label.

Research prototypes also have constraints that product histories often omit. An experimental system might support a feature to explore its semantics, yet still need work in portability, performance, interfaces, or reliability before broad deployment. The project progressed through versions, and its own history records early operational milestones: a first “demoware” system became operational in 1987, version 1 was released to a small group in 1989, and later versions refined the architecture.

From POSTQUEL toward SQL and PostgreSQL

Early POSTGRES did not begin as the present PostgreSQL server. The initial project used a query language called POSTQUEL, which extended ideas from QUEL used in INGRES. The language and system changed as the software moved beyond its research setting. In 1994, Berkeley students Andrew Yu and Jolly Chen added SQL capabilities to the system, and the resulting project was released as Postgres95. It was later renamed PostgreSQL to emphasize both its lineage and its SQL support.

This transition is easy to misstate. SQL did not appear in the original 1986 design in the same form used by current PostgreSQL, and PostgreSQL is not just a renamed research binary preserved unchanged. It is better described as a descendant: the code and architectural ideas came through POSTGRES, while interfaces, query languages, implementation, governance, and feature sets evolved.

The modern project’s distributed development history also differs from the university research group that initiated POSTGRES. Berkeley eventually concluded its project; the code became the basis for subsequent independent and community development. Today’s PostgreSQL project maintains its own release and governance processes. The connection is historically continuous without erasing the changes.

What this history says about database innovation

POSTGRES is a useful case study in research becoming infrastructure. It began with a question about richer database abstractions, implemented those ideas in a concrete system, and created a software lineage that later adapted to SQL and community development. Not every experiment had to survive unchanged for the project to matter. Research can influence later systems through code, terminology, design patterns, and the experience of discovering where an abstraction is hard to implement.

It also demonstrates why database history cannot be told only through query-language milestones. Data models, storage engines, extensibility, concurrency, and application workloads all shape a system. POSTGRES explored how a database could make domain-specific data and behavior first-class while still offering centralized storage and query processing. That ambition continues in modern databases, where extension APIs, custom types, indexing methods, and procedural languages remain active design concerns.

To verify a claim about POSTGRES, begin with the original design paper and related Berkeley technical reports. Use PostgreSQL’s historical documentation for its own lineage and release chronology, but do not treat today’s documentation as a substitute for the original system’s semantics. Distinguish the 1980s research project, the 1990s SQL-oriented transition, and the current project. That timeline preserves both the technical ambition and the substantial evolution that turned an academic system into enduring software.

Related:

Sources: