Learn SQL with PostgreSQL - History, RDBMS Concepts & Why Choose PostgreSQL

#Introduction

Welcome to episode 1 of the Learn SQL with PostgreSQL series! In episode 0, we prepared the entire environment: the PostgreSQL server running via Docker, psql ready to use, and GUI clients installed. Now it's time to step back for a moment to understand why relational databases exist, who created them, and why PostgreSQL has become such a popular choice in the modern world.

These "why" questions aren't just trivial knowledge. When you understand the conceptual foundation, the design decisions in later episodes — such as why data is normalized, why transactions have ACID properties, or why PostgreSQL uses MVCC for concurrency — will feel logical and natural. On the other hand, learning SQL without understanding its foundations is like learning to type fast without understanding the meaning of the words you type.

In this episode, we'll cover the long history of relational databases from Edgar F. Codd's paper in 1970, PostgreSQL's evolution from the Ingres project at UC Berkeley to the official name we know today, the reasons why PostgreSQL deserves to be called the most advanced database in its class, and we'll end with an objective comparison against MySQL, MariaDB, and SQLite.

#The Birth of the Relational Data Model

Before the 1970s, databases weren't what you know today. Data was stored in complex hierarchical and network models, where programmers had to navigate pointers manually from one record to another. Even simple queries could require very long code, and changing the data structure meant rewriting the entire application.

#The Revolution from Edgar F. Codd

Everything changed when Edgar F. Codd, an IBM researcher, published the monumental paper titled "A Relational Model of Data for Large Shared Data Banks" in 1970. In that paper, Codd proposed a revolutionary new way of thinking:

• Data is stored in relations (which we know as tables) made up of rows and columns.
• Each relation has a defined structure with data types on each column.
• Data is accessed through mathematical operations based on set theory and predicate logic — not pointer navigation.
• Users declare WHAT they want, not HOW to retrieve it.

At the time, this idea was considered too theoretical and too slow for the era's hardware. But over time, it proved that the relational approach was far easier to understand, more flexible, and easier to maintain than previous models.

#SQL Standardization

After Codd published his theory, IBM built a prototype called System R that introduced a query language named SEQUEL (Structured English Query Language). This name was later shortened to SQL (Structured Query Language) due to trademark issues. Early commercial systems such as Oracle and DB2 followed, and in 1986-1987, ANSI and ISO officially established SQL as an international standard.

Since then, the SQL standard has continued to evolve: SQL-92, SQL:1999, SQL:2003, up to SQL:2016 which introduced JSON functions. PostgreSQL is known as one of the databases that most seriously pursues compliance with this standard.

#PostgreSQL's Evolution

PostgreSQL didn't appear overnight. It is the result of a long, highly iterative research journey that began at the University of Berkeley, California.

#From Ingres to Postgres95 to PostgreSQL

This story began in 1986 when Michael Stonebraker and his team at UC Berkeley built a database system called Postgres (short for Post-Ingres). This name came about because Postgres was built after a previous project called Ingres — and Postgres itself was intended as a more advanced successor generation.

The journey can be summarized in the following table:

The name "PostgreSQL" itself was chosen because the project was no longer just a "post-Ingres" — it had become a database with full SQL support and continued to evolve. People often just call it "Postgres", and both are officially correct.

#A Healthy Open Source Ecosystem

PostgreSQL is developed by a global community through an open source project model managed by an organization called the PostgreSQL Global Development Group. No single company owns PostgreSQL — the result is a vendor-neutral, community-controlled database that continuously receives contributions from individuals and large companies like Amazon, Microsoft, and Google.

#Why Choose PostgreSQL?

Now that we understand the history, here's the practical question: why PostgreSQL? Below are the main reasons that make it the database of choice in the modern world.

#Strictest SQL Standard Compliance

PostgreSQL is known as the open source database that takes ANSI SQL compliance most seriously. Many standard features are fully supported — from FULL OUTER JOIN, window functions, to FETCH FIRST n ROWS ONLY — while some other databases still implement non-standard syntax. The result: the SQL skills you learn in PostgreSQL are easily transferable to other databases.

SELECT product_name, price
FROM products
ORDER BY price DESC
FETCH FIRST 5 ROWS ONLY;

#Advanced Data Types

PostgreSQL provides a very rich set of data types beyond the standard: JSONB for semi-structured documents, Array for lists of values, UUID for global identity, HSTORE for simple key-value pairs, up to Range Types for date and number ranges. We'll break down JSONB and Array in depth in episode 8.

#Extensibility: Extensions

One of PostgreSQL's greatest strengths is its extensible architecture. Almost anything can be added through extensions: pgvector for AI embeddings and similarity search, PostGIS for geographic data, up to pg_cron for a job scheduler inside the database. This extension ecosystem is what earned PostgreSQL the nickname "the database for everything".

#Concurrency Performance with MVCC

PostgreSQL handles many users accessing data simultaneously through MVCC (Multi-Version Concurrency Control). In essence, every transaction sees a snapshot of the data as it was when it started, so readers are never blocked by writers and writers are never blocked by readers. This is an important foundation we'll dissect thoroughly in episode 11.

SELECT pg_backend_pid();

#PostgreSQL vs MySQL / MariaDB / SQLite

To make the decision to choose PostgreSQL feel objective, let's compare it with other popular databases in the open source ecosystem:

The objective conclusion: MySQL excels in deployment simplicity and the traditional web ecosystem (LAMP), SQLite excels in embedded and single-user scenarios, while PostgreSQL excels in features, SQL standards, and flexibility for complex and large-scale applications. This is why many modern companies — from startups to enterprises — make PostgreSQL their primary database.

#Closing

In this episode 1 we've traced the long journey of relational databases: from Edgar F. Codd's revolutionary 1970 paper that introduced the relational model, the standardization of SQL by ANSI and ISO, PostgreSQL's evolution from the Ingres project at UC Berkeley into an open source database managed by a global community, the reasons why PostgreSQL has become a top choice, to an objective comparison with MySQL, MariaDB, and SQLite.

Key takeaways:

• The relational model was born from Edgar F. Codd's 1970 paper — data is stored in relations/tables, accessed with SQL.
• PostgreSQL evolved from the Ingres → Postgres → Postgres95 → PostgreSQL project at UC Berkeley.
• PostgreSQL excels in SQL standard compliance, advanced data types, extensibility, and MVCC.
• MVCC allows many users to read and write simultaneously without blocking each other.
• Comparing databases isn't about "who's best" — it's about when a tool is the right fit for your needs.

In episode 2, we'll build our first technical foundation: relational design concepts, data normalization, and Data Definition Language (DDL) — starting from Entity Relationship Diagrams, Primary Keys and Foreign Keys, the normalization principles from 1NF to BCNF, up to the CREATE DATABASE and CREATE TABLE commands. Get your psql ready, because the next episode is full of queries you can practice directly!