Before Figma built their famous sharding system, they did something far less glamorous and far smarter: they bought themselves years of runway with a migration so simple it barely makes the highlight reel.
The single Postgres instance was approaching its limits, but horizontal sharding — splitting one table's rows across many machines — wasn't ready (it's a huge project). They needed breathing room now, without the months-long sharding effort. The answer was vertical partitioning.
There are two ways to split a database. Horizontal splitting (sharding) takes one big table and scatters its rows across machines — powerful, but it breaks joins and transactions and needs a shard key. Vertical partitioning is gentler: you take whole tables and move them to separate databases. The files tables go here, the users tables go there. Each table stays intact.
Vertical is dramatically easier because you never split a table's rows — queries within a table group still work normally. It doesn't scale forever, but it relieves a single overloaded database fast.
Figma moved groups of related tables onto their own databases. The clever part is the cutover, done with near-zero downtime: they set up logical replication to copy a table group to its new home and keep it in sync, then used PgBouncer (a connection pooler) to briefly pause incoming connections, let replication catch up to the exact moment, promote the new database, and resume. Clients see a momentary stall, not an outage.
Worth knowing
The sequencing is the masterclass. Vertical partitioning and horizontal sharding aren't competitors — they're stages. Figma did the cheap, low-risk vertical split to survive the immediate crunch, which bought the time to build DBProxy properly for the harder horizontal problem. Doing the expensive thing first, under pressure, is how migrations go wrong.
The gap it reveals
People conflate 'scaling the database' with 'sharding,' as if there's one move. The realisation is that there's a ladder: vertical partitioning (move tables) is rungs below horizontal sharding (split rows), far cheaper, and often enough for years. Knowing to climb the cheap rung first — and how to cut over with PgBouncer + logical replication at near-zero downtime — is migration judgment.
In the interview room
When you say 'the database is the bottleneck,' don't jump straight to sharding. The senior move is to walk the ladder: read replicas, then vertical partitioning by table group, then horizontal sharding only if still needed. Explaining the near-zero-downtime cutover (pause connections, sync replica, promote) shows you've actually moved production data, not just drawn the end state.
The reframe
The best engineers optimise for time as much as for the final architecture. The elegant end-state (sharding) is worthless if you fall over before you finish building it. Figma's vertical-partitioning step looks unremarkable precisely because it worked: it quietly bought the runway that made the impressive part possible.
Don't build the cathedral while the house is on fire. Do the cheap fix that buys time, then build it right.
Primary source →
figma.com — The Growing Pains of Database Architecture