PostgreSQL vs MySQL at scale: how real companies scaled each

Published 2026-10-19 · Built only from first-party engineering write-ups in our database. Every number below comes from the linked source.

Both scale to very large workloads in our database. On PostgreSQL, OpenAI runs ChatGPT on a single primary with nearly 50 read replicas, and Figma and Notion sharded Postgres themselves (a custom query proxy at Figma, workspace-keyed logical shards at Notion). On MySQL, GitHub runs 5.5 million QPS across 50+ clusters, Slack (2.3 million QPS) and Shopify's Shop app shard with Vitess, and Meta's TAO caches a graph stored in sharded MySQL.

PostgreSQL vs MySQL: side by side

PostgreSQLMySQL
Stories in our database1911
CompaniesAtlassian, Datadog, Figma, GitLab, Neon, Notion, OpenAI, PlanetScale, Supabase, Tiger Data (Timescale) and ZalandoCanva, Cloudflare, GitHub, Meta, PlanetScale, Shopify and Slack
Published2021–20262013–2026
Techniques alongside itconnection pooling (3), horizontal sharding (3), query optimization (3), read replicas (3)caching (3), database migration (3), horizontal sharding (3), connection pooling (2)
Scale numbers stated in sourcesone primary and multiple replicas per shard (PlanetScale); 64-bit hashed keyspace split across shards (PlanetScale); restores in seconds even at 100 TB (Neon)99.99% production availability target (Cloudflare); hundreds of millions of users (Canva); $5.1 million sales/minute (Black Friday 2025 peak) (Shopify)

Verdict

The difference in these stories is tooling, not raw limits. The MySQL teams often reach for Vitess to shard. The Postgres teams here leaned on PgBouncer, read replicas and sharding in their own application layer.

Two deep dives worth reading in full: OpenAI's single-primary Postgres for ChatGPT and Shopify's Redis-to-MySQL inventory reservations.

Counts are stories in How They Scaled tagged with each side, see the PostgreSQL and MySQL pages. They describe what these teams wrote about, not market share or benchmark results.

PostgreSQL in other scaling stories

PlanetScale · 2026

Designing a planned switchover for minimum disruption

When a Neki shard's primary has to step aside for a pod replacement, kernel upgrade or cell move, PlanetScale does a planned switchover instead of stopping Postgres the way Patroni does, so a failed switchover can quickly fall back to the old primary. Admin, Neki's control plane, first validates shard state, the target replica, logical failover slots and Postgres settings. Routers then proactively buffer primary-bound queries, the primary defaults new transactions to read-only, and the other replicas are disconnected to pin a final WAL position the target must replay. If the target can't catch up before a deadline, a config reload makes the old primary writable again. Buffered queries are replanned against the new primary, so apps see added latency instead of errors, and every acknowledged commit is on the target when it is promoted.

one primary and multiple replicas per shardsynchronous replication ANY 1 across eligible replicasplanned switchoverquery bufferingsynchronous replicationPostgreSQLNekiKubernetes
PlanetScale · 2026

Shard design doesn't start from your tables

In Neki, PlanetScale's sharded Postgres, a shard group is the unit of co-location: tables in the same group that hash their shard key the same way (xxhash into a 64-bit keyspace split by key ranges) always land on the same shard. Sharding customers, orders, items and addresses by customer_id keeps single-customer queries and transactions on one shard, which matters because a transaction across two shards gets no atomic commit or shared snapshot. Lookup tables become reference tables copied to every shard, catalog tables get their own group keyed on lower(sku), range and modulo indexes support legacy schemes, and a global secondary index routes queries like orders by id without fanning out. Shard groups can be changed later with the Reshard workflow.

64-bit hashed keyspace split across shardscross-shard transactions commit per shard, no atomic commitshard groupsco-locationreference tablesPostgreSQLNekixxhash
Neon · 2026

Inside branch-based restores in Lakebase Postgres

Traditional managed Postgres PITR provisions a new compute+disk monolith, pulls a snapshot out of object storage, and replays WAL—hours at large size—while a survey Neon cites of 50 production Postgres developers found 30% down 3+ hours after a critical failure. Lakebase splits compute from durable history: safekeepers quorum-ack WAL, a pageserver materializes page versions, and object storage keeps immutable history, with 99.99999% of reads served from local caches. A restore is then a metadata branch at a timestamp rather than a copy-and-replay, so time-to-restore drops to seconds even for a 100 TB database.

restores in seconds even at 100 TB99.99999% of reads served from local cachesstorage/compute separationbranch-based PITRWAL to pagesPostgreSQLLakebaseobject storage
PlanetScale · 2026

118 million queries per second on Neki

PlanetScale benchmarked Neki, its sharded Postgres, with single-shard primary-key point selects. Targeting about 200K QPS per shard, it went from 5 shards (about 1M QPS) to 50 (9.9M QPS, per-shard rate within 0.8%) to 512 shards and 480 routers, sustaining 118.5M QPS for 16 minutes over 1.22 PiB with a p99 of 6.06 ms at the router and about one error per 1.8 million queries. PlanetScale notes the run was read-only, primary-only with no replicas, and had no failover during the measured window.

118.5M QPS sustained for 16 minutes512 shards, 480 routershorizontal shardingbenchmarkinglinear scalabilityPostgreSQLNekiAWS r8g.16xlarge
Datadog · 2026

When failover isn't safe: Building high-availability PostgreSQL on Kubernetes

A gameday that injected network latency into one availability zone left several of Datadog's Kubernetes-based PostgreSQL clusters stuck: replicas lagged past Patroni's maximum_lag_on_failover, so no standby could be promoted safely. Datadog moved to a hybrid model: standbys in the leader pool take part in synchronous replication (one synchronous standby, synchronous_mode_strict, synchronous_commit=remote_apply) while read replicas stay asynchronous. pgbench showed remote_apply raised average latency by 53% and cut throughput by 34%, yet production clusters saw no measurable impact after a gradual rollout, and synchronous replication is now enabled in all of its clusters.

+53% avg write latency with remote_apply (pgbench TPC-B)-34% tps with remote_apply (pgbench TPC-B)synchronous replicationfailoverhigh availabilityPostgreSQLKubernetesPatroni
Datadog · 2026

When upserts don't update but still write: Debugging Postgres performance at scale

Datadog tracks last-seen time for millions of ephemeral hosts so inactive ones can be deleted after 7 days. An ON CONFLICT DO UPDATE upsert meant to touch each host at most once a day still locked the conflicting row and wrote Heap LOCK plus COMMIT WAL records even when the WHERE clause skipped the update—at 500 upserts/sec that roughly doubled write IOPS and quadrupled WAL syncs, and at 25,000/sec it would overwhelm a single writer. Using pg_walinspect and a debugger on heap_lock_tuple, they replaced it with an ON CONFLICT DO NOTHING CTE plus a conditional UPDATE that generates no WAL on true no-ops, keeps HOT updates when a day has passed, and preserves correctness for coarse host tracking.

25,000 upserts/sec target in largest DCs500 upserts/sec doubled write IOPS and ~4x WAL syncs in a small DC rolloutquery optimizationHOT updatesWAL inspectionPostgreSQLpg_walinspect
OpenAI · 2026

Scaling PostgreSQL to power 800 million ChatGPT users

OpenAI runs ChatGPT on a single-primary Postgres with nearly 50 global read replicas. Reads are offloaded, write-heavy shardable workloads move to Cosmos DB, and PgBouncer, cache leasing and multi-layer rate limits keep the primary safe.

800 million usersmillions of QPSread replicasconnection poolingcachingPostgreSQLAzurePgBouncer
Zalando · 2025

Contributing to Debezium: Fixing Logical Replication at Scale

Zalando's Fabric Event Streams provisions Debezium-in-embedded micro-apps so teams declare Postgres-sourced Kafka streams on Kubernetes; at peak the connectors handle hundreds of thousands of events per second across 100+ clusters, and have processed billions of events since 2018. Uncontrolled WAL growth on low-activity databases was the top operational issue until a pgjdbc keepalive flush advanced replication slots without table traffic. When newer Debezium hard-disabled that flush, Zalando contributed lsn.flush.mode (including connector_and_driver) and offset.mismatch.strategy (including trust_slot / trust_greater_lsn) so operators can opt into keepalive flushes while choosing whether the slot or the offset store wins on restart—both shipped in Debezium 3.4.0.Final.

hundreds of event streams from Postgreshundreds of thousands of events/sec at peaklogical replicationWAL managementopen source contributionPostgreSQLDebeziumKubernetes
Atlassian · 2025

Migrating the Jira Database Platform to AWS Aurora

Atlassian migrated about four million Jira databases from RDS Postgres to Aurora, balancing reliability, downtime and cost.

4 million databasesdatabase migrationmulti-tenancycost optimizationPostgreSQLAWS AuroraAWS RDS
Datadog · 2025

Breaking up a monolith: How we're unwinding a shared database at scale

Datadog is splitting its large shared Postgres database into team-owned instances in three phases. Logical separation moves tables into about 30 private domain schemas with explicit ACLs, using query samples and interviews with 30+ teams. Access reduction routes services through per-team PG Proxies so ACLs can be narrowed safely, and physical separation replicates each schema to a managed OrgStore instance, moves reads first and then writes with under five seconds of downtime, and replicates back for rollback. Two workloads have fully migrated and more than 70 dead tables were deleted along the way.

30+ teams consulted~30 domain schemas createddatabase decompositionlogical separationproxy-based cutoverPostgreSQLPgBouncerPG Proxy
Figma · 2024

How Figma's Databases Team Lived to Tell the Scale

Figma's nine-month effort to horizontally shard its Postgres stack using a custom query proxy and logical sharding before physical splits.

horizontal shardingquery proxyonline migrationPostgreSQLAWS RDS
Tiger Data (Timescale) · 2023

How We Scaled PostgreSQL to 350 TB+

Timescale dogfooded its own Postgres extension to build a database-observability product, using hypertables, columnar compression and tiered storage to keep a 350 TB+ dataset queryable.

350 TB+10 billion new records/daypartitioningcompressiontiered storagePostgreSQLTimescaleDB
Supabase · 2023

Supavisor: Scaling Postgres to 1 Million Connections

Supabase load-tested Supavisor, its Elixir Postgres pooler, with a million client connections.

1 million connections20,000 QPSconnection poolingbenchmarkingPostgreSQLElixir
Notion · 2023

The Great Re-shard: adding Postgres capacity (again) with zero downtime

Notion tripled its Postgres fleet by re-sharding with logical replication and careful PgBouncer cutovers, with no downtime.

reshardinglogical replicationzero downtimePostgreSQLPgBouncer
Figma · 2023

The growing pains of database architecture

How Figma moved from one Postgres instance to multiple databases by vertically partitioning table groups.

vertical partitioningread replicasconnection poolingPostgreSQLAWS RDS
GitLab · 2022

We are splitting our database into Main and CI

GitLab.com split CI tables into their own Postgres database to relieve its main database.

vertical partitioningdecompositionPostgreSQLRuby on Rails
Figma · 2021

LiveGraph: real-time data fetching at Figma

Figma built LiveGraph, which tails the Postgres replication log so its UI can subscribe to live query results.

change data capturereal-time synccachingPostgreSQLGraphQL
Notion · 2021

Herding elephants: Lessons learned from sharding Postgres at Notion

Notion split its Postgres monolith into a fleet of logical shards keyed by workspace, using double-writes and backfills to migrate.

horizontal shardingonline migrationdouble writesPostgreSQLAWS RDS
GitLab · 2021

Why we spent the last month eliminating PostgreSQL subtransactions

GitLab traced replica stalls to Postgres subtransaction overflow and removed subtransactions from its code.

query optimizationread replicasPostgreSQLRuby on Rails

MySQL in other scaling stories

Cloudflare · 2026

Inside Hyperdrive: How we solved a rare Hyperdrive MySQL caching bug

Hyperdrive, Cloudflare's distributed connection pooler for Workers, keeps warm database connections on its network and can cache common query results in the CDN cache. Taking its MySQL support from beta to GA meant finding bugs like utf8 being a 3-byte alias (fixed with utf8mb4) and COM_RESET_CONNECTION silently resetting the charset to the server default. The hardest was an empty-result bug seen by the highest-volume MySQL customer in about 0.001% of queries, only with caching on. Each Hyperdrive instance has a Client node next to the Worker and an Endpoint node near the database, and they share a cache when they run in the same data center. Because drivers like Node's mysql2 don't support CLIENT_DEPRECATE_EOF, the Client rewrites results into the Worker's capabilities, so the two nodes were caching different bytes for the same query and could read each other's entries. Caching one canonical encoding no matter which node stores it fixed the bug, and Client connection success reached 99.99%.

99.99% production availability targetbug hit ~0.001% of queriesconnection poolingcachingprotocol translationMySQLWorkersHyperdrive
Canva · 2026

Session revocations at scale

Canva keeps 12 hours of session revocations in memory on every gateway, but hundreds of pods each loading over a million revocations from MySQL on deploy caused a stampede on the database. A worker now packs revocations into sorted 16-byte records in 30-minute chunks on S3, using conditional PUTs for optimistic concurrency and ZooKeeper leader election to avoid conflicts, and reaches over 2,000 revocations per second. Gateways binary-search the downloaded bytes directly and poll with conditional GETs, which shrank the cache by 87.5% and cut the revocation database down to two read replicas kept for redundancy.

hundreds of millions of usershundreds of thousands of session checks/seccachingobject storageoptimistic concurrency controlMySQLAmazon S3ZooKeeper
Shopify · 2026

We replaced Redis with MySQL for inventory reservations—and it scaled

Shopify moved checkout inventory reservations from Redis to MySQL using one row per sellable unit, a bounded pool of 1,000 rows per item/location and SELECT ... FOR UPDATE SKIP LOCKED. The real ceiling was connections held by other checkout code: tagging SQL by business process and measuring hold time in ProxySQL found it, and the cleanup removed 50% of reads and 33% of transactions on the primary.

$5.1 million sales/minute (Black Friday 2025 peak)database migrationdual writesquery optimizationMySQLRedisProxySQL
Shopify · 2024

Horizontally scaling the Rails backend of Shop app with Vitess

Shopify's Shop app adopted Vitess to shard its Rails backend, covering keyspace design and the migration plan.

horizontal shardingdatabase migrationMySQLVitessRuby on Rails
GitHub · 2023

Upgrading GitHub.com to MySQL 8.0

How GitHub upgraded its whole MySQL fleet to 8.0 with staged replicas and a working rollback path.

5.5 million QPS300+ TBfleet upgradereplicationrollback planningMySQL
PlanetScale · 2022

One million queries per second with MySQL

PlanetScale benchmarked a horizontally sharded Vitess cluster up to one million QPS.

1 million QPShorizontal shardingbenchmarkingMySQLVitess
GitHub · 2021

Partitioning GitHub's relational databases to handle scale

GitHub defined schema domains and linted cross-domain queries so it could move table groups onto separate MySQL clusters.

vertical partitioningschema domainsonline migrationMySQLRuby on RailsVitess
Shopify · 2021

Shard Balancing: Moving Shops Confidently with Zero-Downtime at Terabyte-scale

Shopify rebalances MySQL shards by moving individual shops online with its Ghostferry tool.

terabyte scaleshard rebalancingonline migrationzero downtimeMySQLGhostferry
Shopify · 2021

Read Consistency with Database Replicas

Shopify routes reads to MySQL replicas while giving apps consistency guarantees such as monotonic reads.

read replicasconsistencyMySQL
Slack · 2020

Scaling Datastores at Slack with Vitess

Slack's multi-year migration from active-active MySQL pairs to Vitess, so data could be sharded by any key, not only workspace.

2.3 million QPShorizontal shardingdatabase migrationMySQLVitess
Meta · 2013

TAO: The power of the graph

TAO is Facebook's geo-distributed graph cache over sharded MySQL, serving the social graph at more than a billion reads per second.

over 1 billion reads/secmillions of writes/seccachinggeo-distributiongraph data modelMySQLMemcache

FAQ

Which is better at scale, PostgreSQL or MySQL?

Our stories don't show a winner: both run at very large scale (OpenAI's ChatGPT on Postgres, GitHub's 5.5 million QPS on MySQL). What differs is the scaling toolkit: Vitess is common for MySQL sharding, while the Postgres teams here built their own sharding or relied on replicas and PgBouncer.

How do companies shard PostgreSQL?

Figma used a custom query proxy and logical sharding before physical splits. Notion used logical shards keyed by workspace, migrated with double writes, and later re-sharded with logical replication.

How do companies shard MySQL?

Slack, Shopify's Shop app and PlanetScale's benchmark use Vitess. Shopify also moves individual shops between MySQL shards online with Ghostferry.

The best scaling write-ups, weekly

One email a week. No spam.

Open subscribe page

More comparisons

Cassandra vs ScyllaDB at scaleMongoDB vs Cassandra at scaleGo vs Rust for backend services at scaleEnvoy vs Nginx at scaleRedis vs MySQL at scaleClickHouse vs Postgres for analytics at scaleetcd vs SQLite for a control planeAurora vs RDS PostgresSharding vs partitioningRead replicas vs sharding

All comparisons →