The hard part of sharding a database isn't splitting the data. It's that ten years of application code was written assuming the data was never split.
Figma ran on a single Postgres instance — the biggest one AWS rents, an r5.24xlarge, already upgraded from the 12xlarge. At peak it sat at 65% CPU. Traffic was growing roughly 3x a year. The wall wasn't theoretical; it had a date on it.
Sharding means splitting one giant database into many smaller ones, each holding a slice of the rows. In a diagram it's trivial: draw one cylinder, then draw three. Done.
The reality is brutal, and here's why. Every query your application has ever written assumed all the data lived in one place. JOIN two tables? Easy when they're on the same machine — impossible-by-default when one table's rows are scattered across three. A transaction touching several rows? Trivial in one database, a distributed-systems problem across many. You're not splitting data. You're invalidating a decade of assumptions baked into thousands of queries.
Why "just use NoSQL" was the wrong answer
The tempting move is to abandon Postgres for a database that shards natively. Figma refused — and the reasoning is the interesting part. They had a mountain of battle-tested Postgres-specific code and operational knowledge. Throwing that away to escape a scaling limit would trade a known problem for a thousand unknown ones. So they chose the harder path: keep Postgres, and teach the application to shard on top of it.
The centrepiece is DBProxy, a query-routing layer written in Go that sits between the application and the databases. The application sends ordinary SQL, believing it talks to one database. DBProxy does the real work:
1. parse the incoming SQL into an AST 2. inspect the AST for the shard key (e.g. file_id) 3. route single-shard queries to one physical db scatter-gather multi-shard queries, then merge 4. reject queries it cannot safely route
That last step is the unsung hero. Rather than silently doing something dangerous with a query it can't route correctly, DBProxy refuses it — turning a potential data-correctness disaster into a loud, fixable error at development time.
Logical shards, decoupled from physical machines
Figma's sharpest design decision: separate logical shards from physical ones, using Postgres views. Data is assigned to a logical shard by its key; logical shards are then mapped onto physical databases. When you need to rebalance, you move a logical shard to a new machine — the data's identity never changes. This turns the terrifying "re-shard the whole database" operation into a routine "relocate a logical shard" one.
Choosing the shard key without guessing
Pick the wrong shard key and you've cemented hot shards and cross-shard joins into your architecture. Figma built a shadow application readiness framework: it ran candidate sharding schemes against real production query patterns before committing, surfacing which queries would break or fan out. They shipped their first sharded table in September 2023 — after the framework proved the key choice would hold.
The gap it reveals
Anyone can say "shard the database." The senior-level realisation is that sharding is fundamentally an application problem disguised as a database problem — your queries, joins, and transactions are what break, not the storage. Engineers who haven't lived it draw three cylinders and move on. Engineers who have, ask about the shard key and the cross-shard queries first.
In the interview room
The instant you say "I'll shard," the follow-ups are: what's your shard key, which queries now cross shards, and how do transactions work across them? Naming a key and walking through one query that gets harder because of it is worth more than any amount of "horizontally scalable" hand-waving. Bonus points for decoupling logical from physical shards out loud.
The reframe
Figma's win wasn't a clever sharding algorithm — those are in textbooks. It was refusing to throw away a decade of working code to chase an elegant rewrite, and instead building the boring, careful machinery (a proxy, a logical/physical split, a shadow-testing framework) to evolve what they had. The constraint they respected wasn't technical. It was institutional knowledge.
The data was never the hard part. The assumptions written on top of it were.
Primary source →
figma.com — How Figma's Databases Team Lived to Tell the Scale