Platform / Sharding

One logical database across many servers.

Sharding distributes data across servers while the application continues to use a single database endpoint. Shopify, Slack, Uber, and Cash App use this architecture for terabyte-to-petabyte datasets.

Sharding with Vitess Get sharding help

Benefits

The operational benefits of sharding.

Massive tables

A single table can span many servers and trillions of rows. Resharding adds horizontal capacity as the dataset grows beyond one machine.

Fast backups

Backups run in parallel across shards, reducing backup windows and allowing individual shard restores to replace failed servers quickly.

I/O headroom

IOPS and throughput demand spreads across many servers, expanding aggregate capacity with each shard.

Failure isolation

Query pressure and disk failures stay contained to an individual shard, reducing the blast radius for the full dataset.

Vertical and horizontal

Two ways to split.

Vertical shardingkeeps each table on one server but spreads the tables across many. Two 1 TB tables get dedicated servers; the small ones share. The application still sees one database through the proxy layer.

Horizontal shardingsplits the rows of one large table across servers. A trillion-row table becomes four shards of 500 GB, and the routing layer tracks which rows live where.

The shard key decides the distribution, usually through a hash of an ID column. A well-chosen key produces even distribution and local queries. An uneven key creates hot shards and costly migrations, so we validate that choice with workload data.

  row  ──▶  hash(user_id)  ──▶  shard range

     ┌────────────┬────────────┬────────────┐
     │  -55       │  55-aa     │  aa-       │
     │ ┌────────┐ │ ┌────────┐ │ ┌────────┐ │
     │ │ 500 GB │ │ │ 500 GB │ │ │ 500 GB │ │
     │ └────────┘ │ └────────┘ │ └────────┘ │
     └────────────┴────────────┴────────────┘
        one logical table, three servers

Who needs it

Signals it is time to shard.

Many workloads remain unsharded for their lifetime. These signals indicate that a single primary is approaching its practical limit.

You are at or near the largest available instance size
Extra IOPS and throughput dominate the monthly bill
Backups take too long and lock contention keeps showing up
You are planning for growth and want the scaling path built in

Shard with people who have done it before.

Enterprise plans include query-pattern analysis, load testing, and shard-key design grounded in your production access patterns.

Talk to us How Vitess shards

row ──▶ hash(user_id) ──▶ shard range ┌────────────┬────────────┬────────────┐ │ -55 │ 55-aa │ aa- │ │ ┌────────┐ │ ┌────────┐ │ ┌────────┐ │ │ │ 500 GB │ │ │ 500 GB │ │ │ 500 GB │ │ │ └────────┘ │ └────────┘ │ └────────┘ │ └────────────┴────────────┴────────────┘ one logical table, three servers