PostgreSQL
PostgreSQL is not just an open source database.
It is the result of nearly four decades of academic and industrial evolution.
Born in 1986 at the University of Berkeley as an evolution of Ingres, the original POSTGRES project introduced concepts that were ahead of its time: extensibility, custom data types, rules and an advanced relational model.
In 1996 SQL support was added and the name became PostgreSQL.
The world, however, kept calling it simply “Postgres”.
And that’s perfectly fine.
In this section I explore PostgreSQL from an architectural and operational perspective: design, performance, security and technical decisions applicable to real-world environments.
Because choosing PostgreSQL is not just choosing an open source database.
It is choosing an engine designed to be extended, analyzed and truly understood.
VACUUM and autovacuum: why PostgreSQL needs someone to clean up
A 200 GB PostgreSQL database with tables bloated to three times their actual size. Autovacuum was enabled but poorly configured. How to diagnose bloat, read pg_stat_user_tables, and tune without disabling anything.
Roles and Users in PostgreSQL: Why Everything Is (Only) a ROLE
PostgreSQL does not distinguish between users and roles: everything is a ROLE. The correct mental model, a real case, and a complete example to build a truly maintainable read-only account.
When a LIKE '%value%' Slows Everything Down: A Real PostgreSQL Optimization Case
A real-world PostgreSQL performance case where a LIKE '%value%' caused a full scan and degraded response times. Analysis, execution plan, and a scalable indexing strategy.
EXPLAIN ANALYZE is not enough: how to actually read a PostgreSQL execution plan
A real-world case where the optimizer chose a nested loop on 2 million rows because statistics were stale. How to read an execution plan, spot the red flags, and fix the root cause.