Sharding vs partitioning: real examples from Figma, GitHub and Notion

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

Partitioning splits data into smaller pieces; sharding is partitioning rows across separate database servers. In our database, vertical partitioning means moving whole table groups to their own database, as Figma, GitHub (schema domains) and GitLab (a separate CI database) did. Horizontal sharding splits rows of the same tables across servers, as Figma, Notion, Slack and Shopify did. Figma's posts show both in order: vertical partitioning (2023), then horizontal sharding (2024).

Sharding vs Partitioning: side by side

ShardingPartitioning
Stories in our database116
CompaniesDatadog, Discord, Figma, Meta, Notion, PlanetScale, Shopify, Slack and StripeDiscord, Figma, GitHub, GitLab, LinkedIn and Tiger Data (Timescale)
Published2017–20262016–2023
Stack in these storiesPostgreSQL (4), MySQL (3), Vitess (3), AWS RDS (2)PostgreSQL (3), Ruby on Rails (2), AWS RDS (1), Cassandra (1)
Scale numbers stated in sources118.5M QPS sustained for 16 minutes (PlanetScale); 1.5 PB (Stripe); 1 million QPS (PlanetScale)350 TB+ (Tiger Data (Timescale)); billions of messages (Discord)
Direct comparison storyFigma: The growing pains of database architecture; Figma: How Figma's Databases Team Lived to Tell the Scale(same story)

Verdict

Partition first when whole table groups can move apart. Shard when a single table group outgrows one database. Figma's two posts show that sequence.

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

The direct comparison

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

Sharding in other scaling stories

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
Stripe · 2024

How Stripe's document databases supported 99.999% uptime with zero-downtime data migrations

Stripe's DocDB and its Data Movement Platform move data between shards without downtime.

1.5 PB99.999% uptimeshardingshard migrationzero downtimeMongoDBDocDB
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
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
Datadog · 2023

Husky: Exactly-once ingestion and multi-tenancy at scale

A deep dive on how Husky routes, shards and ingests events exactly once across tenants.

exactly-once ingestionshardingmulti-tenancyGoKafkaFoundationDB
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
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
Meta · 2021

ZippyDB: Facebook's key value store

Meta's general-purpose distributed key-value store built on RocksDB, with shard management and configurable consistency.

replicationshardingtunable consistencyRocksDBPaxos
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
Discord · 2017

How Discord Indexes Billions of Messages

Discord built message search on many small Elasticsearch clusters, sharding by guild and indexing lazily through a queue.

billions of messagesshardingqueuessearch indexingElasticsearchPython

Partitioning in other scaling stories

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
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
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
Discord · 2017

How Discord Stores Billions of Messages

Early story of Discord outgrowing MongoDB and moving messages to Cassandra with a channel+time-bucket partition key.

billions of messages120 million messages/daydatabase migrationdata modelingpartitioningCassandraMongoDB
LinkedIn · 2016

FollowFeed: LinkedIn's Feed Made Faster and Smarter

LinkedIn moved its feed to a fan-out-on-read system that keeps member timelines in memory and on RocksDB.

fan-out on readpartitioningrankingJavaRocksDB

FAQ

What is the difference between sharding and partitioning?

Partitioning splits data into pieces. Sharding is the kind of partitioning where the pieces live on separate database servers. Vertical partitioning moves whole tables; horizontal sharding splits the rows of a table.

Should you partition before sharding?

Figma did: it moved table groups onto multiple Postgres databases first (2023 post), then horizontally sharded (2024 post). GitHub and GitLab describe vertical partitioning without horizontal sharding in the posts we track.

What partitioning examples are there inside one database?

Timescale uses hypertables to partition a 350 TB+ Postgres dataset, Discord partitioned Cassandra messages by channel plus time bucket, and LinkedIn's FollowFeed partitions member timelines.

The best scaling write-ups, weekly

One email a week. No spam.

Subscribe

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 scalePostgreSQL vs MySQL at scaleetcd vs SQLite for a control planeAurora vs RDS PostgresRead replicas vs sharding

All comparisons →