I've been collecting first-hand scaling write-ups, and five of them are tagged horizontal sharding: Figma, Notion, Slack, Shopify and PlanetScale. Figma, Notion and Slack are the most useful to compare, because they took noticeably different routes. Shopify and PlanetScale fill in the rest of the picture.

Figma: buy time first, then shard logically

Figma's story is really two posts.

The first, The growing pains of database architecture (2023), is the "put it off" chapter. Figma moved from one Postgres instance to multiple databases by vertically partitioning table groups, using read replicas and connection pooling along the way. No sharding yet, just moving whole groups of tables to their own databases.

The second, How Figma's Databases Team Lived to Tell the Scale (2024), is the real thing: a nine-month effort to horizontally shard its Postgres stack on AWS RDS. Two ideas stand out:

• A custom query proxy. The application talks to a proxy, and the proxy works out which shard a query belongs to. That keeps routing logic out of every service.
• Logical sharding before physical splits. Figma first made the system behave as if it were sharded, then moved data onto separate physical databases afterwards.

That second point is the one I'd copy. It splits a terrifying project into two smaller ones. You prove your routing and query patterns work while all the data still sits in one place, and only then do the risky data move.

Notion: shard by workspace, then do it again

Notion's Herding elephants: Lessons learned from sharding Postgres at Notion (2021) is a classic for a reason. Notion split its Postgres monolith into a fleet of logical shards keyed by workspace.

The workspace is a natural shard key for a product like Notion: most reads and writes stay inside one workspace, so most queries only ever touch one shard.

To move the data, Notion used double writes and backfills: write new data to both the old and new locations, copy the historical data over, then switch reads once the two match.

Then the sequel. In The Great Re-shard: adding Postgres capacity (again) with zero downtime (2023), Notion tripled its Postgres fleet by re-sharding with logical replication and careful PgBouncer cutovers, with no downtime.

The lesson here is that sharding isn't a one-time project. If you pick the right key and use logical shards, adding capacity later becomes "move shards to more machines" rather than "redesign the schema."

Slack: shard by any key, not just workspace

Slack's Scaling Datastores at Slack with Vitess (2020) is the interesting contrast. Slack ran MySQL as active-active pairs and spent several years migrating to Vitess, a sharding layer for MySQL. The post cites 2.3 million QPS.

The key reason: Slack wanted to shard data by any key, not only by workspace.

That's the opposite lesson from Notion, and both are right for their products. Notion's data mostly lives inside a workspace. Slack has data that doesn't fit that model cleanly, so a workspace-only scheme became a limit. Vitess let Slack pick the shard key per table instead of forcing one for everything.

If you're choosing a shard key today, ask: what's the biggest thing in my product that crosses tenant boundaries? If the answer is "not much," shard by tenant. If it's "a lot," plan for more than one key.

What Shopify adds: design the keyspace, then keep rebalancing

Shopify has two sharding posts on MySQL.

• Horizontally scaling the Rails backend of Shop app with Vitess (2024) covers how the Shop app adopted Vitess to shard a Rails backend, including keyspace design and the migration plan.
• Shard Balancing: Moving Shops Confidently with Zero-Downtime at Terabyte-scale (2021) covers the day-two problem: shards get uneven, so Shopify moves individual shops between shards online with its Ghostferry tool, at terabyte scale.

Together they make the same point Notion's re-shard does. Getting sharded is the start. You also need a safe, boring way to move one tenant at a time.

What PlanetScale adds: a ceiling check

One million queries per second with MySQL (2022) is a benchmark, not a production story. PlanetScale load-tested a horizontally sharded Vitess cluster up to one million QPS. It's useful as a sanity check on how far the Slack and Shopify approach can stretch, as long as you read it as a load test.

Five patterns across all five stories

1. Delay it honestly. Figma vertically partitioned first. Splitting table groups apart is often enough for a while.
2. Put a routing layer in the middle. Figma built a query proxy. Slack, Shopify and PlanetScale use Vitess. Either way, the app shouldn't hard-code where data lives.
3. Separate logical from physical. Figma sharded logically before splitting physically, and Notion's logical shards made its re-shard possible.
4. Choose the key from your product, not the database. Workspace worked for Notion. Slack needed more flexibility.
5. Budget for moving data forever. Double writes and backfills (Notion), logical replication (Notion again), Ghostferry (Shopify). Every team ended up needing a way to move data while the product stayed up.

The honest summary

None of these teams sharded early, and none of them describe it as easy. Figma's took nine months. Slack's took years. What they share is that they made the data move a separate, testable step, and they planned for doing it again.

All five horizontal sharding stories, with stack and scale details, are on one page: Horizontal sharding: real scaling case studies. There's a broader sharding page too, with Discord's guild-sharded Elasticsearch search, Meta's ZippyDB, Stripe's DocDB and Datadog's Husky.

Have you sharded by tenant and regretted it, or gone multi-key and wished you hadn't? I'd love to hear about it in the comments.

Here's what each story adds, in roughly the order you'd hit these problems.

1. One primary can go a very long way

The most surprising entry is also the newest. In Scaling PostgreSQL to power 800 million ChatGPT users (January 2026), OpenAI describes running ChatGPT on a single-primary Postgres with nearly 50 global read replicas, serving millions of queries per second.

The trick isn't one clever feature. It's a stack of protections around that primary:

• reads are pushed to replicas,
• write-heavy workloads that can be sharded move to Cosmos DB instead of landing on Postgres,
• PgBouncer handles connection pooling,
• cache leasing and multi-layer rate limits stop traffic spikes from reaching the database.

My takeaway: before you design a sharding scheme, ask which workloads actually need to live on the primary. Moving the shardable, write-heavy ones somewhere else can buy you years.

2. Connections are a resource, so pool them

Connection count is a quiet limit that bites early. Two stories lean on PgBouncer (OpenAI above, and Notion's re-shard below), and Supabase went further and built its own pooler.

In Supavisor: Scaling Postgres to 1 Million Connections (2023), Supabase load-tested Supavisor, a Postgres pooler written in Elixir, with one million client connections at 20,000 QPS. Keep in mind this is a load test, not a production incident report, but it shows how far you can push the "many clients, few real connections" model.

3. Watch for small features with big side effects

Why we spent the last month eliminating PostgreSQL subtransactions is my favourite kind of post: a whole month spent on something that looks tiny. GitLab traced stalls on its read replicas to Postgres subtransaction overflow, and the fix was removing subtransactions from its code.

The lesson I take from it: if your replicas lag or stall under load and nothing obvious changed, look at what your ORM or app code is doing per transaction, not just at hardware.

4. Split by domain before you shard

Two teams solved "one database is too busy" without sharding at all:

• Figma, in The growing pains of database architecture (2023), moved from one Postgres instance to several databases by vertically partitioning groups of tables, alongside read replicas and connection pooling.
• GitLab, in We are splitting our database into Main and CI (2022), moved its CI tables into their own Postgres database to take load off the main one.

Vertical partitioning works when your tables naturally fall into groups that rarely join each other. It's usually less risky than sharding because each group still lives in one ordinary database.

5. When you do shard, pick the key your product already has

Eventually Figma and Notion both had to shard horizontally.

• In Herding elephants (2021), Notion split its Postgres monolith into a fleet of logical shards keyed by workspace, migrating with double writes and backfills.
• In How Figma's Databases Team Lived to Tell the Scale (2024), Figma describes a nine-month effort built on a custom query proxy, with logical sharding before physical splits.

That "logical first" idea is worth stealing. If your app already routes queries by shard key while the data still sits in one place, the physical move becomes a separate, smaller project.

6. Plan for sharding twice

Sharding isn't one and done. In The Great Re-shard (2023), Notion tripled its Postgres fleet by re-sharding with logical replication and careful PgBouncer cutovers, with no downtime.

If you shard, design for moving data between shards from day one, because you'll need to.

7. The replication log is an API

Two stories treat Postgres replication as more than a backup:

• Figma's LiveGraph (2021) tails the Postgres replication log so the UI can subscribe to live query results.
• Notion's re-shard (above) used logical replication to copy data into new shards.

Once you see the log as a stream you can build on, real-time features and migrations get a lot easier.

8. Shape the data for how it's queried

How We Scaled PostgreSQL to 350 TB+ (2023) is Timescale using its own Postgres extension for a database-observability product. The dataset is 350 TB+ with 10 billion new records a day, kept queryable with hypertables (time-based partitioning), columnar compression and tiered storage.

For append-heavy time-series data, partitioning by time plus compressing and tiering older data is often a better move than adding more servers.

9. Sometimes the scale is the number of databases

The last story flips the usual problem. In Migrating the Jira Database Platform to AWS Aurora (2025), Atlassian moved about four million Jira databases from RDS Postgres to Aurora, weighing reliability, downtime and cost along the way.

When you run a database per tenant, the hard part is fleet automation, not query tuning.

The pattern, in one list

If I had to turn these 11 stories into a checklist:

1. Offload reads to replicas and move shardable write-heavy work off the primary.
2. Pool connections early.
3. Profile what your app does inside transactions.
4. Split table groups into separate databases before sharding.
5. Shard by the tenant key your product already has, logically first.
6. Build for re-sharding.
7. Use logical replication for migrations and real-time features.
8. Partition, compress and tier time-series data.

None of this is new on its own. What's useful is seeing which steps real teams took, and in what order.

All 11 stories, with stack, techniques and the scale numbers each post states, are on one page: How teams scaled PostgreSQL. If you know a good first-hand Postgres scaling post I've missed, I'd love to hear about it in the comments.