Sharding is the technique of splitting a large database across multiple machines so that each machine owns only a slice of the data. It is one of the most powerful — and most over-applied — scaling strategies in software engineering. Most teams reach for it a decade too early. This guide explains how it works, when you actually need it, and which 2026 tools make it survivable.
What changed in 2026
- Managed distributed databases matured. CockroachDB 23.x, Citus 12, and Vitess 18 handle automatic rebalancing, schema migrations, and cross-shard transactions without the DIY complexity of earlier years.
- PostgreSQL 17 native partitioning improved. Declarative table partitioning with partition pruning now rivals simple sharding for many time-series and multi-tenant workloads — without leaving the single-node Postgres model.
- NVMe and cloud vertical scaling raised the bar. A single
r8g.16xlarge on AWS gives you ~2 TB RAM and ~100k IOPS. Vertical scaling got much cheaper, pushing the sharding threshold higher.
- PlanetScale/Vitess popularized application-level sharding patterns for MySQL users without requiring them to build the routing layer.
How sharding works
A shard is an independent database instance that holds a partition of the full dataset. A shard key (or partition key) determines which shard owns each row.
User ID 1–999_999 → Shard A (us-east-1 DB)
User ID 1M–1_999_999 → Shard B (us-west-2 DB)
User ID 2M+ → Shard C (eu-west-1 DB)
The application (or a proxy like ProxySQL/Vitess) routes each query to the correct shard based on the key in the WHERE clause.
Sharding strategies
| Strategy |
How it works |
Best for |
| Range sharding |
Rows are split by value ranges (IDs 0–1M, 1M–2M…) |
Time-series, ordered data |
| Hash sharding |
Hash of shard key → shard number |
Uniform distribution, user data |
| Directory sharding |
Lookup table maps keys to shards |
Complex tenancy, custom routing |
| Geographic sharding |
Shard by region/country |
Data residency, latency |
When you actually need sharding
- Single-node writes are saturated — you've added replicas but write throughput is the bottleneck.
- Dataset size exceeds vertical scaling — your table is measured in tens of TB and doesn't fit on the largest available instance.
- Regulatory data residency — you must keep EU user data in EU datacenters (geographic sharding solves this without full sharding complexity).
- Multi-tenant SaaS isolation — per-tenant sharding gives hard isolation boundaries for compliance or noisy-neighbor reasons.
Before you shard: alternatives to try first
- Proper indexing — a missing composite index is often the real problem.
- Read replicas — offload analytics and reporting reads from the primary.
- Vertical scaling — bigger instance class is often cheaper than the engineering cost of sharding.
- Table partitioning — PostgreSQL native partitioning handles multi-TB tables without distributing across nodes.
- Caching layer — Redis or Memcached absorbs read spikes.
- CQRS + a read-optimized store — separate write and read models.
How to pick a shard key
A good shard key is:
- High cardinality — enough distinct values to distribute data evenly.
- Even distribution — no hotspot (don't shard by
status if 90 % of rows are active).
- Query-aligned — the majority of queries filter by this key so routing is deterministic.
- Stable — changing the shard key of an existing row means moving the row.
-- Bad shard key: status column with few values → hotspot
PARTITION BY LIST (status) -- 'active' shard gets 90% of traffic
-- Good shard key: user_id hash → even distribution
PARTITION BY HASH (user_id) PARTITIONS 16
Managed sharding options
Citus (PostgreSQL extension) — adds hash-distributed tables to Postgres; queries still look like standard SQL; good for analytics and multi-tenant apps.
CockroachDB — fully distributed, automatic rebalancing, serializable transactions across shards; write latency is higher than single-node Postgres.
Vitess — MySQL sharding proxy used by YouTube and PlanetScale; handles resharding online, connection pooling, and schema migrations safely.
PlanetScale — hosted Vitess with branching workflow; zero-downtime schema changes.
Common mistakes
Choosing a low-cardinality shard key. Sharding by country when 70 % of your users are in one country creates a hotspot immediately.
Cross-shard joins. Application-layer joins across shards are expensive. Denormalize or co-locate related data on the same shard.
Skipping foreign keys. Distributed databases can't enforce cross-shard FK constraints. You must handle referential integrity in the application.
Not planning for rebalancing. Range shards fill unevenly over time. Design your rebalancing strategy before you need it.
What to skip
- DIY sharding middleware — routing logic, connection pooling, and rebalancing built in-house is a 2-year distraction. Use Vitess, Citus, or CockroachDB.
- Sharding for perceived future scale — "we might get 10× traffic" is not a reason to shard today. Premature sharding costs more than it saves.
- Sharding a write-light, read-heavy workload — read replicas are simpler and probably sufficient.
FAQ
Can I shard PostgreSQL without extensions?
Yes — using declarative partitioning and Postgres foreign data wrappers you can distribute tables, but it is significantly more manual than Citus or CockroachDB.
How many shards should I start with?
Start with 4–16. More shards means more operational overhead. You can always add shards later with a managed platform.
Do ORMs work with sharded databases?
Partially. Most ORMs don't understand shard routing natively. You need to ensure the ORM always includes the shard key in queries, or use a proxy that handles routing transparently.
What is resharding and how painful is it?
Resharding redistributes data to a different number of shards. With managed tools (Vitess online rebalancing, CockroachDB automatic rebalancing), it can be done with no downtime. DIY resharding typically requires a maintenance window and a careful migration plan.
Where to go next