How Figma Scaled Postgres from One Overloaded Database to Vertical Partitioning and Horizontal Sharding

Figma's single Postgres instance hit its vertical scaling ceiling as product growth exploded. The team escaped by vertically partitioning tables across logical databases, then horizontally sharding the largest ones.

Data & Storage · advanced · 12 min read · 2124 words · By Sandip Das · Published

Public postmortem: based on what the organisation published. Sources are listed below.

What this covers

  1. Background
  2. What Happened
  3. Root Cause
  4. Detection and Response
  5. Impact
  6. The Fix
  7. Lessons for Your Team
  8. Apply It Yourself

Key components

  • Vertical Partitioning — Split the monolithic Postgres instance into domain-aligned databases (files, users, collaboration) to isolate workloads and reduce contention before attempting horizontal sharding.
  • Horizontal Sharding — Distributed the largest tables (files domain) across multiple Postgres instances using a shard key, allowing write and storage capacity to scale beyond a single node.
  • PgBouncer (transaction pooling mode) — Multiplexed thousands of application-layer connections onto a small pool of real Postgres server connections, preventing max_connections exhaustion across all database instances.
  • Zero-downtime live migration tooling — Custom tooling using logical replication and dual-write patterns allowed data to be migrated from the monolith to new instances without any planned downtime or feature freeze.
  • Autovacuum tuning — Per-table autovacuum configuration prevented dead tuple accumulation and table bloat on high-write tables, a problem that worsens severely when many domains share a single instance.
  • Amazon RDS — The managed Postgres hosting platform used by Figma, whose instance size limits formed the hard vertical ceiling that made the migration necessary.

Background

Figma is a browser-based collaborative design tool. By the time this scaling effort became necessary, the product had grown to serve millions of designers and teams storing files, components, comments, and version history. All of that data lived in a single PostgreSQL instance running on Amazon RDS.

According to Figma's own postmortem, the company's data volume and query load had grown to the point where the monolithic Postgres instance was approaching its practical vertical ceiling. The team could keep buying larger RDS instance types, but that path had a hard end. The write-ahead log (WAL), the shared buffer pool, connection counts, and vacuum pressure were all converging on limits that money alone could not solve. The postmortem does not publish exact row counts or QPS figures, but it describes the situation as an existential risk to product reliability.

The engineering challenge was not just technical. Figma's product teams were shipping continuously. Any database migration had to happen with zero planned downtime, without freezing feature development, and without introducing correctness bugs in a system where collaborative real-time editing makes data consistency critical.

The rest of this case study — the trade-offs, the scaling numbers and the build prompt — is available to LearnXops members. Create an account or see membership.

Sources

Topics: postgres, database scaling, sharding, partitioning, data engineering, postmortem

Related case studies

Browse all case studies