What Makes PostgreSQL Different — Architecture & Philosophy

This course assumes real, working SQL knowledge — mysql2 and mysql3 already cover SELECT, JOINs, subqueries, CTEs, window functions, and query optimization in depth, and that knowledge transfers directly to Postgres, since both are SQL. This course is deliberately not going to re-teach any of that. Instead, every chapter asks the same question: what does Postgres actually do differently from the MySQL this site already covers, and why does it matter?

Two Relational Databases, Two Different Origins

MySQL began as MySQL AB, was acquired by Sun Microsystems in 2008, and then by Oracle in 2010 — it's now owned outright by a single corporation, dual-licensed under the GPL and a commercial license. PostgreSQL began as the POSTGRES project at UC Berkeley in 1986 under Michael Stonebraker, and is now developed by the PostgreSQL Global Development Group — a community-driven governance model with no single owning company, released under the permissive, MIT/BSD-style PostgreSQL License.

This isn't just trivia — it has real practical consequences. There's no dual-licensing tension to navigate with Postgres, no single vendor who could change licensing terms or direction unilaterally, and new features land based on community and committer consensus rather than one company's own product roadmap.

Standards-Compliance-First Design Philosophy

Postgres has historically prioritized strict SQL standard compliance and correctness over convenience shortcuts — stricter type checking, and a general unwillingness to silently coerce or truncate data rather than raising an error. MySQL's own historical trade-off leaned toward speed and ease of use, with looser default behavior in older versions (permissive date validation, silent truncation).

Process-Per-Connection vs. Thread-Per-Connection

Postgres gives each client connection its own operating system process — full process isolation, meaning one connection crashing can't directly take down another connection or the server as a whole. Processes are heavier to spawn than threads, though, which is exactly why connection poolers like PgBouncer become important at real scale. MySQL instead handles each client connection as a thread within a single shared server process — threads are lighter-weight to create, but a serious bug in one thread's handling puts the entire mysqld process genuinely at risk, since threads share memory space far more directly than isolated processes do.

This is a real architectural choice with real trade-offs, not an accident — the same category of decision c3-3 covered when it demonstrated a genuine race condition using pthreads: shared memory between concurrent execution units buys speed at the cost of a whole class of bugs that simply can't happen when each connection is a fully separate process instead.

When to Choose Each

This isn't "Postgres is better" — both are excellent, mature, production-proven engines, and plenty of real organizations run both simultaneously for different workloads.

This Course's Own Roadmap

Hands-On Exercises