A 2012 Pinterest talk described MySQL sharding where every object ID is 64 bits holding a shard ID, a type and a local ID, with room for 65,536 shards of which only the first 4,096 were opened on 8 physical servers of 512 databases each. A smaller team wants to copy the scheme for 6 TB of data. Estimate what the design buys, and where it runs out.

The assumptions, stated

Facts from the talk slides: IDs embed the shard, the ID space allows 65,536 shards, 4,096 were opened first, and the initial layout was 8 servers with 512 databases each. My assumptions for the copy: 6 TB of data now, spread evenly, and growth of 10x over three years. These are labelled estimates, not Pinterest figures.

The arithmetic

• Opened shards: 4,096 logical databases. 6 TB / 4,096 = about 1.5 GB per logical database.
• At 10x growth, 60 TB / 4,096 = about 15 GB each, still small enough that one database file moves between hosts in minutes.
• Hosts: 4,096 / 8 = 512 databases per server today. Growing to 40 servers means about 102 databases per server, achieved by moving whole databases, not by changing IDs.
• Headroom: 65,536 / 4,096 = 16x more shards could be opened later without changing the ID format.

The number, with its range

The design buys about 10 to 16x of growth without rewriting a single ID or a routing table. The reason is mechanical: because the shard is part of the ID, the application finds the data from the ID alone, and adding hardware means moving whole logical databases and updating a small map from shard ranges to hosts.

Which assumption dominates

Evenness of data across shards. If one user's data (a celebrity account) is huge, that logical database is 100x its neighbours, and since data stays in its shard it cannot be split. The ID design makes routing free but gives up the ability to rebalance one hot shard.

What it rules in or out

It rules in a one-database-type, key-lookup-heavy workload such as pins and boards fetched by ID. It rules out queries across users (global search, joins between shards) which must go elsewhere. It also fixes the ceiling: past 65,536 shards the format itself must change.

When this is the wrong answer

At 6 TB a single well-tuned database with read replicas often does fine, and sharding early adds operational cost that only pays off when writes or data size exceed one machine. Copy the idea of putting routing into the ID only when growth makes a single database a real risk.

Common weak answers

• "Sharding by user ID modulo N is equivalent." Changing N then moves almost all data; here moving is whole-database and the mapping stays stable.

What a strong answer adds

Plan for the big-shard exception: decide in advance what a one-off oversized tenant gets, such as a dedicated shard range.