When MySQL Is the Right Answer (Honestly): A Counter-Narrative for 2026
This page is for the teams that have been told to migrate to Postgres but should not. Here are the five situations where MySQL or MariaDB is correct in 2026.
You are running Vitess at scale
YouTube created Vitess to scale MySQL to Google-scale OLTP. Slack, GitHub (historically), and Booking.com all run Vitess. The track record for sharded OLTP with Vitess is ~15 years of production at the largest scale in the industry. Citus (Postgres equivalent) is younger and well-maintained by Microsoft, but does not have the same depth of battle-testing at multi-billion-row sharded OLTP. If your scale needs match Vitess and you have or can build the team, MySQL via Vitess is the rational choice in 2026.
You are deeply in the LAMP / WordPress / Drupal / Magento ecosystem
WordPress powers roughly 40% of the web and is MySQL-native. The wp-db class, most plugins, and the entire hosting ecosystem assume MySQL or MariaDB. There have been community attempts at Postgres compatibility (HyperDB-PG, PostgreSQL for WordPress) but they are not first-class. Magento is MySQL-only by design. If your platform is WordPress, Magento, or a deeply integrated LAMP stack, MySQL or MariaDB is the correct choice. Trying to run these on Postgres is fighting the ecosystem and will cost engineering hours that deliver no user value.
Your team has 5-15 years of MySQL operational depth
The migration cost includes throwing away accumulated operational knowledge. MySQL DBAs who deeply understand InnoDB tuning, binlog replication topology, XtraBackup operational runbooks, and ProxySQL pooling have built real value. Postgres operational expertise (Patroni/etcd for HA, PgBouncer transaction mode tradeoffs, autovacuum tuning, WAL management) is a different skillset. If your team's DBA bench is MySQL-deep and your Postgres depth is shallow, the migration cost includes a multi-quarter operational learning curve. That is a real cost.
You are committing to Oracle Cloud and MySQL HeatWave
MySQL HeatWave is Oracle's in-memory OLAP accelerator. Oracle's performance claims for analytical workloads on OCI are real (verified by independent benchmarkers in limited contexts, though most data is vendor-sourced). HeatWave is available on OCI and AWS. If Oracle Cloud is your infrastructure commitment and analytical query performance on MySQL data is a primary workload, HeatWave provides genuine value. The lock-in is also real: HeatWave-tuned schemas are OCI/AWS-specific. Evaluate with open eyes.
You need MySQL compatibility but want open governance: use MariaDB
MariaDB is the open-governance fork of MySQL, created by original MySQL founder Monty Widenius in 2009. The MariaDB Foundation (non-profit) governs the project with no single corporate owner. MariaDB 11.x is the current series. Wikipedia runs MariaDB. Some Google internal teams use MariaDB. ServiceNow's OEM stack includes MariaDB. If your requirement is MySQL-compatible SQL dialect without Oracle dependency, MariaDB is the answer. Note that MariaDB and MySQL have diverged at the high end (JSON syntax, storage engines, optimiser behaviour); test your workload against the specific MariaDB version you plan to use.
When NOT to use this counter-narrative as cover
If you do not fit clearly into one of the five situations above, the correct default answer in 2026 is Postgres. The ecosystem, governance, and feature trajectory of Postgres are all positive. The Supabase, Neon, and Render defaults exist because Postgres is correct for most new applications.
Do not reach for MySQL out of habit or because it was the right answer ten years ago. The market has moved. The Stack Overflow Developer Survey has Postgres as the most admired database since 2022 for a reason. Choose MySQL because your situation genuinely fits one of the five; not as the path of least resistance from 2015.