INGRES and QUEL: A Rival Path to Practical Relational Databases
Berkeley's INGRES project helped prove that relational databases could be built outside IBM, while its QUEL language showed that SQL was not the only plausible declarative interface for the relational model.
The relational model produced more than one implementation lineage
It is easy to retell relational database history as a straight line from Edgar Codd to IBM System R to SQL. Berkeley’s INGRES project makes that story less tidy and more accurate. Michael Stonebraker, Eugene Wong and a changing group of students built an independent relational system with its own language, optimizer choices and implementation philosophy.[1]
INGRES mattered because relational ideas were still contested. A theory of tables and relational operations was not enough; researchers had to show that a usable system could execute queries efficiently on real hardware.
Stonebraker and Wong began the project in the early 1970s
Historical accounts place the start of the Berkeley relational work in 1973, after Stonebraker and Wong became interested in Codd’s relational ideas. By 1974, Berkeley technical reports were already documenting the preliminary design of INGRES, including its query language, storage and access architecture.[4][5] The project developed through prototypes, rewrites and user feedback rather than appearing as a finished architecture all at once.
By 1976, the Berkeley team published a detailed account of the design and implementation of INGRES, documenting a working relational database management system rather than only a data model.[1]
QUEL offered a declarative language that was not SQL
INGRES used QUEL, a query language based on relational calculus. Berkeley documentation describes a language built around range declarations and commands such as retrieve, append, delete and replace.[3]
Like SQL, QUEL let users describe desired data at a higher level than physical record navigation. But its syntax and conceptual roots were different, showing that declarative relational access did not imply one inevitable language.
The language competition was historically real
SQL eventually became the industry standard, but that outcome should not be projected backward. During the 1970s and early 1980s, QUEL was a credible interface attached to a serious relational implementation. The existence of multiple languages helped turn the relational model from one laboratory design into a broader systems movement.
INGRES made query processing an engineering problem
The 1976 implementation paper describes the machinery needed to turn high-level relational requests into executable operations: catalogs, access methods, query decomposition and storage structures.[1]
This was the practical heart of relational computing. If a user no longer specified the exact path through the data, the database system had to choose a path on the user’s behalf.
Query modification became a reusable architectural idea
INGRES also used query rewriting techniques to implement views, integrity constraints and protection. Instead of building a separate mechanism for every policy, the system could transform a user’s query before execution. That idea became one of Stonebraker’s influential contributions to database architecture.[2]
The project learned through repeated redesign
Iteration turned research into a usable system
Stonebraker’s 1980 retrospective is unusually valuable because it records mistakes as well as successes. He describes phases in which the team moved from making INGRES work at all to making it efficient, reliable and maintainable enough for users.[2]
That history is a useful corrective to invention stories. Important systems are often not one clean insight; they are a sequence of decisions revised under pressure from performance, maintainability and real users.
Berkeley distributed the software and expanded its influence
Distribution multiplied the project’s descendants
INGRES escaped the laboratory through academic distribution and later commercialization. MIT’s account of Stonebraker’s Turing Award notes that INGRES and POSTGRES helped spawn multiple later database products and companies.[4]
The line from research code to commercial infrastructure became a recurring pattern in Stonebraker’s career and in database systems generally.
SQL’s victory did not make QUEL historically irrelevant
The database market ultimately standardized around SQL, and commercial INGRES itself moved toward SQL support. But QUEL remains important because it records a period when relational language design was still open.
Its existence separates two milestones that are often collapsed: the success of the relational model and the success of SQL. They were related, but they were not the same event.
Why INGRES belongs beside System R
System R proved that IBM could turn Codd’s ideas into a practical relational system. INGRES proved that the same broad model could be implemented independently with different architectural choices and a different query language.[1][2]
That competition strengthened the relational paradigm. A concept becomes a field when multiple teams can build it, disagree about its details, and still produce working systems.
Works Cited
- 01UC Berkeley — The Design and Implementation of Ingres (1976) digicoll.lib.berkeley.edu
- 02Michael Stonebraker — Retrospection on a Database System (1980) pages.cs.wisc.edu
- 03UC Berkeley — QUEL documentation digicoll.lib.berkeley.edu
- 04MIT News — Michael Stonebraker wins Turing Award news.mit.edu
- 05UC Berkeley EECS — Preliminary Design of INGRES, Part I (1974) www2.eecs.berkeley.edu
CodeHistory is a living archive. Citations document the evidence used for this edition; later evidence may refine the account.
Submit a research lead