How Figma's databases team lived to tell the scale

Original Article ↗ Hacker News Discussion ↗

Distributed DB vs. Sharded Postgres

  • Many argue this is the classic story: start with a single RDS instance, hit scale limits, spend years sharding; some say “just use a distributed database” from day one.
  • Others counter that in 2012–2016, mature distributed SQL options were limited, especially for heavily relational workloads with lots of joins.
  • Several note there’s no free lunch: distributed systems add complexity, cost, and require early, sometimes brittle partition-key decisions.

Cloud Spanner and Cloud Lock‑in

  • Spanner is praised as “magical” internal Google tech with strong guarantees, but seen as:
    • Expensive.
    • A deep lock‑in to GCP, which many distrust due to perceived product churn and past sunsetting/pricing issues.
  • Some would prefer inferior tech they control over superior but vendor‑tied tech; others say Spanner’s managed consistency/replication can be worth the premium.

Per‑Tenant Databases vs Logical Sharding

  • Many wonder why not one DB (or schema) per customer, avoiding cross‑tenant transactions.
  • Reported pros: simpler mental model, isolation, easier backups, shifting big tenants between nodes.
  • Reported cons: migration/schemas become painful at thousands of tenants; noisy neighbors still exist if tenants share a physical instance; Postgres metadata and migrations can become bottlenecks.
  • Some teams report great success with thousands of tenant schemas; others report abandoning the approach as unmanageable.

Existing Postgres / NewSQL Options

  • Commenters note similarity to Citus or Vitess and speculate why those weren’t used:
    • RDS doesn’t support extensions like Citus.
    • Earlier Citus limitations (coordinator bottlenecks, join restrictions).
    • Risk and effort of full migration vs incremental sharding on known RDS Postgres.
  • NewSQL systems (CockroachDB, Yugabyte, TiDB) are seen as attractive for greenfield, but:
    • Introduce new operational learning curves.
    • May have worse latency/throughput for some workloads.
    • Still require complex, high‑risk data migrations at Figma’s scale.

Cost, Risk, and Engineering Tradeoffs

  • One calculation suggests in‑house sharding engineering cost could be several million dollars and take years to “pay back” vs managed distributed solutions.
  • Others respond that for a high‑value, fast‑growing product, minimizing migration risk and leveraging existing Postgres/RDS expertise outweigh pure cost optimization.

Other Themes

  • NoSQL is generally viewed as a poor fit for Figma’s highly relational model.
  • Some see the solution as clever but over‑engineered and worry about long‑term maintenance and “key‑person” risk.
  • Aurora Limitless is mentioned but seen as too new and likely very expensive.