Figma की डेटाबेस टीम ने पैमाने के बारे में क्या बताया

Distributed DB vs. Sharded Postgres

• कई लोगों का तर्क है कि यह क्लासिक कहानी है: एक single RDS instance से शुरू करें, scale limits से टकराएँ, और फिर वर्षों sharding में लगाएँ; कुछ लोग कहते हैं कि पहले दिन से ही “just use a distributed database” करें।
• दूसरे लोग जवाब देते हैं कि 2012–2016 में mature distributed SQL options सीमित थे, खासकर उन heavily relational workloads के लिए जिनमें बहुत सारे joins होते हैं।
• कई लोग नोट करते हैं कि free lunch जैसी कोई चीज़ नहीं है: distributed systems complexity, cost, और early, कभी-कभी brittle partition-key decisions जोड़ते हैं।

Cloud Spanner and Cloud Lock‑in

• Spanner को “magical” internal Google tech के रूप में सराहा जाता है, जिसमें strong guarantees हैं, लेकिन इसे इस तरह भी देखा जाता है:
  • महँगा।
  • GCP में गहरा lock‑in, जिस पर कई लोग product churn और past sunsetting/pricing issues की धारणा के कारण भरोसा नहीं करते।
• कुछ लोग ऐसी inferior tech पसंद करेंगे जिसे वे control करते हैं, बजाय superior लेकिन vendor‑tied tech के; दूसरे कहते हैं कि Spanner की managed consistency/replication premium के लायक हो सकती है।

Per‑Tenant Databases vs Logical Sharding

• बहुत से लोग सोचते हैं कि हर customer के लिए एक DB (या schema) क्यों नहीं, ताकि cross‑tenant transactions से बचा जा सके।
• बताए गए pros: सरल mental model, isolation, आसान backups, बड़े tenants को nodes के बीच स्थानांतरित करना।
• बताए गए cons: हजारों tenants पर migration/schemas दर्दनाक हो जाते हैं; noisy neighbors फिर भी रहते हैं अगर tenants एक physical instance साझा करते हैं; Postgres metadata और migrations bottlenecks बन सकते हैं।
• कुछ teams हजारों tenant schemas के साथ शानदार सफलता की रिपोर्ट करती हैं; अन्य लोग इसे unmanageable मानकर छोड़ देने की रिपोर्ट करते हैं।

Existing Postgres / NewSQL Options

• Commenters Citus या Vitess से समानता नोट करते हैं और अनुमान लगाते हैं कि उनका उपयोग क्यों नहीं किया गया:
  • RDS Citus जैसे extensions को support नहीं करता।
  • पहले के Citus limitations (coordinator bottlenecks, join restrictions)।
  • known RDS Postgres पर incremental sharding की बजाय full migration का risk और effort।
• NewSQL systems (CockroachDB, Yugabyte, TiDB) greenfield के लिए आकर्षक माने जाते हैं, लेकिन:
  • नए operational learning curves लाते हैं।
  • कुछ workloads के लिए latency/throughput खराब हो सकती है।
  • Figma के scale पर complex, high‑risk data migrations फिर भी करनी पड़ती हैं।

Cost, Risk, and Engineering Tradeoffs

• एक calculation के अनुसार in‑house sharding engineering cost कई million dollars हो सकती है और managed distributed solutions की तुलना में “pay back” होने में years लग सकते हैं।
• दूसरे जवाब देते हैं कि high‑value, fast‑growing product के लिए migration risk को कम करना और existing Postgres/RDS expertise का लाभ उठाना pure cost optimization से अधिक महत्वपूर्ण है।

Other Themes

• NoSQL को आम तौर पर Figma के highly relational model के लिए poor fit माना जाता है।
• कुछ लोग solution को clever लेकिन over‑engineered मानते हैं और long‑term maintenance तथा “key‑person” risk को लेकर चिंता करते हैं।
• Aurora Limitless का उल्लेख किया गया है, लेकिन इसे बहुत नया और संभवतः बहुत महँगा माना गया है।