History and Philosophy
Ingres to Postgres to PostgreSQL, the extensibility thesis that makes types, operators and index methods first-class, the release cadence and community without a company, the heap-first design contrasted with MySQL's clustered index, and the forks and derivatives built on it.
Ingres to PostgreSQL, and the extensibility thesis
Postgres was designed to be extended. In most databases, a new data type or index structure means changing the server. In Postgres, types, functions, operators, operator classes, index access methods, languages and even table storage are catalogue entries that extensions add at runtime. PostGIS, pgvector, TimescaleDB and Citus all exist because of that decision.
| PostgreSQL | MySQL InnoDB | |
|---|---|---|
| table storage | heap: rows in insertion order, indexes point at (page, item) | clustered: the table is the primary key B+tree |
| MVCC | old versions stay in the heap; vacuum removes them | old versions in undo logs; purge removes them |
| connections | a process each | a thread each |
| secondary index lookup | index → heap tuple directly | index → primary key → clustered index |
| extensibility | types, operators, index methods, FDWs | storage engine API, plugins |
Forks and derivatives: Citus (distributed tables), TimescaleDB (time series), Neon (separated storage and compute), Amazon Aurora PostgreSQL (a log-structured storage layer), and the Postgres wire compatibility of CockroachDB and YugabyteDB. The community has no owning company: development happens on the pgsql-hackers list and commitfests, with yearly majors supported for five years.