Module 1 – PostgreSQL Foundations
Lesson 1 – History and Evolution of PostgreSQL
Introduction
Every mature technology carries the weight of its history.
As Database Administrators, we often begin learning a new database by installing it, creating databases, writing SQL queries, or exploring administration commands. While that approach teaches us how to use a database, it rarely explains why the database behaves the way it does.
PostgreSQL is no exception.
Many of its most defining characteristics—its strict standards compliance, extensibility, stability, community-driven development, and conservative engineering philosophy—are direct consequences of decisions made decades ago.
Understanding PostgreSQL's history is not merely an academic exercise. It is the foundation upon which every subsequent lesson in this series will build.
Before we study architecture, memory management, storage internals, WAL, MVCC, or the query planner, we must first understand why PostgreSQL came into existence and what problems it was originally designed to solve.
Why This Lesson Matters
If you ask an experienced Oracle DBA why Oracle behaves a certain way, the answer often traces back to decades of engineering decisions, commercial priorities, and enterprise requirements.
The same is true for PostgreSQL.
Its architecture is not accidental.
Its development philosophy is not accidental.
Its release model is not accidental.
Each has evolved through years of academic research, engineering discipline, and community collaboration.
By understanding PostgreSQL's origins, you will begin to appreciate why it often approaches familiar database problems differently from Oracle—and why those differences make sense.
This perspective will become increasingly valuable as we progress through more advanced topics.
Who Should Read This?
This lesson is designed for:
Oracle DBAs beginning their PostgreSQL journey.
Database professionals curious about PostgreSQL's origins.
Developers who want to understand the philosophy behind PostgreSQL.
Anyone who believes that understanding the history of a technology helps in understanding its architecture.
No prior PostgreSQL knowledge is required.
Learning Objectives
By the end of this lesson, you should be able to answer the following questions confidently:
Why was PostgreSQL created?
Who created PostgreSQL?
Why is it called PostgreSQL?
Why do many people still call it "Postgres"?
What is the PostgreSQL Global Development Group (PGDG)?
Why has PostgreSQL earned a reputation as one of the world's most reliable enterprise databases?
How did an academic research project evolve into a database trusted by organizations worldwide?
The World Before PostgreSQL
To appreciate PostgreSQL, we must first understand the world into which it was born.
During the 1960s and early 1970s, database systems were fundamentally different from what we use today.
Most applications relied on one of three models:
Hierarchical databases
Network databases
Flat-file storage
Popular systems of the era included IBM IMS, IDMS, and Adabas.
Although revolutionary for their time, these systems shared several limitations:
Data was accessed through complex pointer navigation.
Applications were tightly coupled to the physical structure of the database.
Even small schema changes often required extensive application modifications.
Writing and maintaining database applications demanded significant effort.
In essence, developers had to know how the data was physically organized before they could retrieve it.
The database acted more like a sophisticated file system than an intelligent query engine.
The Relational Revolution
Everything changed in 1970.
Computer scientist Dr. Edgar F. Codd, working at IBM, published one of the most influential papers in the history of computer science:
"A Relational Model of Data for Large Shared Data Banks."
Instead of forcing applications to navigate records manually, Codd proposed a radically different idea:
Store data as relations (tables) and let the database determine the most efficient way to retrieve it.
Conceptually, the difference looked like this:
Before
Application
│
├── Pointer
├── Pointer
├── Pointer
└── Read Data
After
Application
│
▼
SQL Query
│
▼
Database Engine
│
▼
Requested Result
This seemingly simple shift laid the foundation for modern relational databases and eventually for SQL itself.
Nearly every enterprise database in use today—including Oracle, PostgreSQL, SQL Server, MySQL, and DB2—owes its existence to this breakthrough.
The Birth of INGRES
Inspired by Codd's research, the University of California, Berkeley launched the INGRES (Interactive Graphics and Retrieval System) project in 1973.
Led primarily by Michael Stonebraker and Eugene Wong, INGRES became one of the earliest and most influential relational database systems ever built.
Although many people recognize Oracle as one of the pioneers of relational databases, much of the academic research that shaped the industry emerged from projects such as INGRES.
Its influence can still be seen across modern database engines.
Oracle and Berkeley Take Different Paths
Around the same period, Oracle Corporation began commercializing relational database technology.
A simplified timeline illustrates this divergence:
1970
│
├── Edgar Codd publishes the Relational Model
│
1973
│
├── INGRES begins at UC Berkeley
│
1979
│
└── Oracle Version 2 released commercially
From this point onward, the two worlds evolved with different priorities.
Oracle focused on delivering a commercial, enterprise-ready database platform backed by a single company.
Berkeley, meanwhile, continued exploring the future of database technology through research rather than product commercialization.
That distinction continues to influence PostgreSQL today.
Michael Stonebraker and the Next Generation of Databases
Among the many researchers who shaped modern databases, Michael Stonebraker stands out as one of the most influential.
Throughout his career, he contributed to several groundbreaking database projects, including:
INGRES
POSTGRES
VoltDB
SciDB
C-Store
His contributions fundamentally changed how database systems evolved over the following decades and ultimately earned him the ACM Turing Award, often regarded as the "Nobel Prize of Computing."
Why INGRES Was No Longer Enough
By the mid-1980s, computing workloads had changed dramatically.
Organizations were beginning to work with:
Computer-Aided Design (CAD)
Geographic Information Systems (GIS)
Scientific datasets
Engineering applications
Images
User-defined objects
Traditional relational databases struggled to model these increasingly complex workloads.
Stonebraker believed the next generation of databases needed capabilities that conventional systems lacked.
Rather than extending INGRES indefinitely, Berkeley initiated an entirely new research project.
The Birth of POSTGRES
In 1986, the POSTGRES research project officially began.
The name itself reflected its purpose:
POST + INGRES
In other words:
The database that comes after INGRES.
One surprising fact often overlooked by beginners is that POSTGRES did not originally use SQL.
Instead, it introduced its own query language called POSTQUEL.
At the time, SQL had not yet achieved the level of universal adoption it enjoys today.
Ideas That Were Ahead of Their Time
POSTGRES was never intended to be "just another database."
It was an experimental platform designed to explore advanced concepts such as:
User-defined data types
Rules
Table inheritance
Extensibility
Complex objects
Time-travel queries
Many of these ideas would take years—or even decades—to become mainstream within enterprise database systems.
The project deliberately prioritized innovation over commercial success.
Why PostgreSQL Adopted SQL
Although POSTQUEL was technically capable, the software industry had already embraced SQL as the common language for relational databases.
Businesses wanted SQL.
Developers wanted SQL.
Tool vendors wanted SQL.
Without SQL compatibility, POSTGRES would likely have remained an academic curiosity.
Recognizing this reality, developers gradually introduced SQL support into the project.
That decision proved transformational.
PostgreSQL Is Born
In 1996, developers Andrew Yu and Jolly Chen completed the transition to SQL.
To reflect this milestone, the project adopted a new name:
PostgreSQL
The name combines:
POSTGRES — honoring the original research project.
SQL — recognizing full SQL support.
Today, both PostgreSQL and Postgres are officially accepted names for the same database system.
There is no functional distinction between them.
PostgreSQL Is Owned by a Community, Not a Company
One of PostgreSQL's defining characteristics is its governance model.
Unlike Oracle Database, PostgreSQL is not owned by a single corporation.
Its development is coordinated by the PostgreSQL Global Development Group (PGDG)—a worldwide community of experienced database developers and contributors.
Engineers from organizations including AWS, Google, Microsoft, EnterpriseDB, Crunchy Data, Percona, CYBERTEC, Fujitsu, Red Hat, and many others contribute improvements back to the same codebase.
No single organization dictates PostgreSQL's roadmap.
Features succeed through technical discussion, peer review, and community consensus rather than commercial priorities.
Engineering Philosophy Before Feature Count
Perhaps the greatest reason PostgreSQL enjoys its reputation today lies in its engineering philosophy.
Its priorities can be summarized as follows:
Correctness
│
▼
Stability
│
▼
Maintainability
│
▼
Performance
│
▼
New Features
This ordering is intentional.
A feature is not accepted simply because it is innovative or marketable.
It must also be correct, maintainable, and consistent with PostgreSQL's long-term architectural goals.
This conservative philosophy explains why PostgreSQL has earned widespread trust in production environments.
From Research Project to Enterprise Database
Over the following decades, PostgreSQL steadily expanded its capabilities while preserving its architectural principles.
Organizations adopted PostgreSQL because it consistently delivered:
Reliability
Standards compliance
Extensibility
Robust MVCC implementation
Rich indexing capabilities
JSON support
GIS extensions
Strong replication features
Predictable release cycles
Rather than chasing trends, PostgreSQL matured through careful engineering.
Today, it powers financial institutions, government systems, healthcare platforms, scientific research, cloud-native applications, and countless enterprise workloads around the world.
Oracle Perspective
Oracle and PostgreSQL solve many of the same database problems, yet they emerged from fundamentally different backgrounds.
| Oracle | PostgreSQL |
|---|---|
| Commercial product | Community-driven project |
| Single-company ownership | Community governance |
| Closed source | Open source |
| Vendor-controlled roadmap | Consensus-driven roadmap |
| Commercial priorities | Engineering priorities |
| Proprietary ecosystem | Standards-focused ecosystem |
As Oracle DBAs, it is tempting to map PostgreSQL directly onto Oracle concepts.
Resist that temptation.
Throughout this series, our goal is not to force similarities but to understand the reasoning behind PostgreSQL's design choices.
That understanding is far more valuable than memorizing feature comparisons.
Key Takeaways
PostgreSQL originated from the POSTGRES research project at the University of California, Berkeley.
Michael Stonebraker played a foundational role in its creation.
POSTGRES originally used POSTQUEL before adopting SQL.
SQL support in 1996 led to the name PostgreSQL.
"Postgres" and "PostgreSQL" refer to the same database.
PostgreSQL is governed by the PostgreSQL Global Development Group rather than a single company.
Its emphasis on correctness, stability, and maintainability continues to shape its architecture and release philosophy.
What's Next?
Now that we understand where PostgreSQL came from, the next logical question is:
Why was PostgreSQL built the way it was?
In Module 1 – Lesson 2: Why PostgreSQL Exists, we'll explore the design philosophy that distinguishes PostgreSQL from many other database systems and see how those principles influence everything from extensibility to standards compliance and long-term maintainability.
Series Navigation
Previous: Series Introduction & Roadmap
Current: Module 1 – Lesson 1: History and Evolution of PostgreSQL
Next: Module 1 – Lesson 2: Why PostgreSQL Exists
References
PostgreSQL Official Documentation
PostgreSQL Global Development Group
Michael Stonebraker, The Design of the POSTGRES Storage System
Edgar F. Codd, A Relational Model of Data for Large Shared Data Banks (1970)
Author Note
This series is written from the perspective of an Oracle DBA learning PostgreSQL from first principles. Rather than focusing solely on administration commands, our objective is to understand PostgreSQL's architecture, engineering philosophy, and internal mechanisms in the same systematic manner that experienced DBAs approach Oracle internals.
If you're beginning this journey with me, I encourage you not to skip the fundamentals. Every advanced topic we'll cover in later modules—from MVCC and WAL to performance engineering and source code—builds upon the concepts introduced here.
No comments:
Post a Comment