Pinterest's MySQL Sharding
Pinterest sharded MySQL by embedding the shard ID inside every primary key, making any object's location computable from its ID alone with no lookup service.
The design
Pinterest's published account describes a deliberately austere sharding scheme, chosen after trying more sophisticated distributed databases and finding the operational burden unacceptable.
The core idea is a 64-bit ID that encodes its own location: a shard ID, a type ID, and a local sequence — packed into one integer.
The consequences are the point:
- No lookup service. Given an ID, the shard is a bit-shift away. There is no directory to operate, cache, replicate or fail.
- The ID is stable forever, so IDs can be passed everywhere — URLs, caches, other systems — without indirection.
- Shard assignment happens once, at creation, and never changes for that object.
The restrictions they accepted deliberately
No joins across shards. Related data is co-located by construction — a user's pins live on the user's shard — and anything genuinely cross-shard is denormalised or assembled in the application.
No foreign keys, no cross-shard transactions. Referential integrity is the application's responsibility.
No auto-increment. IDs are generated by the application, which is what makes embedding the shard possible.
Denormalisation as the default. Data is duplicated so that reads stay single-shard.
The lesson
Constraints chosen up front are cheaper than capabilities you cannot support later. Every restriction above is one they could not have removed later anyway once data was distributed. By accepting them at design time, they got a system with no moving parts in the routing layer — which is a large operational saving repeated every day.
The contrast with a directory-based mapping (Figma, and most multi-tenant systems) is instructive and both are defensible. Embedded IDs give zero-lookup routing and immovable data. A directory gives movable data — you can rebalance and give a large tenant a dedicated shard — at the cost of operating the directory. Choose by whether you expect to need to move data, which for a consumer product with uniform object sizes is usually no, and for a B2B product with power-law tenants is usually yes.