PostgreSQL — Trivia & Interesting Facts¶
Surprising, historical, and little-known facts about PostgreSQL.
PostgreSQL traces its lineage back to 1986 at UC Berkeley¶
Michael Stonebraker started the POSTGRES project at UC Berkeley in 1986 as a successor to the Ingres database (which he also created). Students Andrew Yu and Jolly Chen added SQL support in 1995 and renamed it PostgreSQL. Stonebraker won the Turing Award in 2014, partly for his work on POSTGRES.
The PostgreSQL elephant mascot is named Slonik¶
The PostgreSQL elephant logo, named "Slonik" (Russian for "little elephant"), was designed in 1996. The elephant was chosen because elephants are known for being reliable, having good memory, and being strong — qualities the community wanted associated with the database. The name Slonik later became the name of a popular PostgreSQL replication tool.
PostgreSQL has been the #1 most loved database in developer surveys¶
PostgreSQL has consistently ranked as one of the most admired databases in Stack Overflow's annual developer survey, overtaking MySQL around 2017-2018. By the early 2020s, it was the most popular database among professional developers, ending MySQL's long reign. This shift happened gradually as PostgreSQL gained features like JSONB, full-text search, and better replication.
VACUUM was PostgreSQL's biggest operational burden for over a decade¶
PostgreSQL's MVCC implementation requires dead tuples to be cleaned up by VACUUM. Before autovacuum was enabled by default in version 8.3 (2008), administrators had to schedule VACUUM manually. Failing to vacuum could cause "transaction ID wraparound," which would force the database to shut down entirely to prevent data corruption — one of the most feared PostgreSQL failure modes.
PostgreSQL supports over 90 built-in data types¶
PostgreSQL ships with native support for geometric types, network addresses (inet, cidr, macaddr), ranges, arrays, JSON, JSONB, XML, UUID, tsvector (full-text search), and many more. Users can also define custom types with operators and index support. This extensibility is one of the key features that differentiates PostgreSQL from other relational databases.
The PostgreSQL community releases a new major version every year like clockwork¶
Since version 10 (2017), PostgreSQL has followed an annual major release cycle, with new versions typically released in September or October. Each major version receives 5 years of support. This predictable cadence is managed entirely by an open-source community with no single corporate sponsor — a remarkable feat of distributed project management.
PostgreSQL's EXPLAIN ANALYZE was considered a revolution in query debugging¶
When PostgreSQL added EXPLAIN ANALYZE (which runs the query and shows actual execution statistics alongside the plan), it was considered revolutionary compared to other databases that only showed estimated plans. Combined with tools like pgBadger and auto_explain, this made PostgreSQL one of the easiest databases to troubleshoot at the query level.
Foreign Data Wrappers let PostgreSQL query almost anything¶
PostgreSQL's Foreign Data Wrapper (FDW) framework, introduced in version 9.1 (2011), allows PostgreSQL to query external data sources as if they were local tables. FDWs exist for MySQL, Oracle, MongoDB, Redis, Elasticsearch, CSV files, LDAP directories, Twitter, and even other PostgreSQL instances. The postgres_fdw is now commonly used for sharding strategies.
A PostgreSQL instance ran for over 10 years without a restart at one company¶
While not officially documented, multiple PostgreSQL users have reported instances running continuously for over a decade. PostgreSQL's architecture — process-per-connection with shared memory — is remarkably stable. The main reasons for restarts are typically OS kernel updates and major version upgrades, not PostgreSQL instability.
PostgreSQL's extension ecosystem includes a full-blown machine learning library¶
The pg_ml (PostgresML) extension, launched in 2022, enables running machine learning models (including XGBoost, LightGBM, and even LLMs) directly inside PostgreSQL. The idea of running ML inside the database — rather than extracting data to an external ML pipeline — represents a full circle back to Stonebraker's original POSTGRES vision of extensible data processing within the database engine itself.