Why every new build goes on PostgreSQL
We have not started a new project on MySQL since 2021. This is the short version of why.
MySQL is a perfectly good database. We maintain several production MySQL systems for retainer clients. We are not in the business of telling teams to migrate something that works. But for new builds, the default is Postgres, and the reasons are mostly small things that add up.
§ 1.0 — JSONB
Real JSON, with an index on it, queryable from SQL. We can model the well-known parts of a domain in tables and the experimental edges in a JSONB column, without needing a second datastore. The Postgres planner treats it as a first-class type.
§ 2.0 — Generated columns and partial indexes
A partial index on WHERE deleted_at IS NULL is a five-line change that quietly halves the size of half of our indexes.
§ 3.0 — Full-text search you can ship
Postgres full-text search is good enough to defer adding Elasticsearch / Algolia for the first year of most projects. We have shipped four production search experiences on plain tsvector in the last 18 months.
§ 4.0 — Logical replication
Standby instances, table-level replication into analytics warehouses, blue/green database migrations. All of this is in the box.
§ 5.0 — The cost of being wrong
Low. ANSI-SQL covers 95% of what we write. The 5% that uses Postgres-specific features could be rewritten in a week if a client insisted on moving. It has never happened.