Default to PostgreSQL for new stateful services

We operate a mix of MySQL 8 and PostgreSQL 15 clusters on our internal Kubernetes platform. New product teams regularly ask which database to pick; SRE maintains runbooks, backup policies, and incident playbooks for both, which doubles operational surface area for the same job: a durable relational store with strong consistency within a service boundary.

MySQL remains the right choice for a long tail of legacy services and for a few vendors that only certify against it. Nothing in this ADR forces a migration off MySQL where there is no engineering owner for the move.

We already run production traffic on PostgreSQL for customer analytics and billing microservices. The team has operational experience; the main gap is social—new services still “default to what the last repo used,” which perpetuates split-brain defaults.

For new stateful services created after 2026-05-01, we standardize on PostgreSQL 15 or newer as the default relational database. Provisioning templates, CI smoke tests, and example repositories will target PostgreSQL first.

Teams may opt out by writing a short ADR that names the alternative and the concrete constraint (vendor support, existing shared cluster, etc.). Opt-out is not the default path in internal templates.

Existing MySQL services stay on MySQL until their owning team proposes a migration with capacity for cutover and replay testing. This decision does not mandate a fleet-wide migration.

Positive. One primary engine for greenfield work shrinks on-call cognitive load: extensions, backup verification, and replica lag triage converge on a single set of dashboards. New hires see one obvious “default” in documentation.

Negative. Teams deeply invested in MySQL-specific tooling may see migration friction if they later need cross-database joins or shared stored procedures; those patterns are already discouraged in service boundaries, but this decision makes the mismatch more visible.

Operational. SRE will retire one of the two “golden path” starter templates after a six-month review if PostgreSQL adoption meets expectations; MySQL templates stay as an explicit secondary path.

Follow-up. Platform will publish a supported matrix of extensions (e.g. pgvector, pg_cron) and a single managed upgrade policy so teams do not fork minor versions ad hoc.