Notion

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.

PgBouncer also sits in front of the single Postgres primary behind ChatGPT. For more write-ups like this one, browse our PostgreSQL scaling case studies.

Published
2023-07-17
Scale
Not stated in source
Techniques
resharding logical replication zero downtime
Stack
PostgreSQL PgBouncer

Try this stack yourself

  • Railway · Deploy something like this on Railway: spin up PostgreSQL plus your app in a few clicks. New accounts get $20 in credit (applied when you pick a paid plan).
    Railway isn't part of Notion's setup in this story. It's just an easy place to try the same building blocks.
  • Better Stack · Monitor uptime and logs with Better Stack, and get alerted fast if a migration or traffic spike goes sideways on your own system.
    Better Stack isn't part of Notion's setup in this story. It's a tool for watching your own systems while you try ideas like these.

Some links above are affiliate links: if you sign up, How They Scaled may earn a commission at no extra cost to you. We only list tools that fit the stack in the story.

See also

Notion architectureClickHouse vs Postgres for analytics at scalePostgreSQL vs MySQL at scaleSharding vs partitioningPostgres connection pool calculator

The best scaling write-ups, weekly

One email a week. No spam.

Open subscribe page

Related stories

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
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
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