Fly Postgres, Supabase द्वारा प्रबंधित

मूल लेख ↗ Hacker News चर्चा ↗

Fly.io, Supabase के साथ साझेदारी करके अपनी infrastructure पर एक fully managed PostgreSQL सेवा पेश कर रहा है, जिससे उन टीमों के लिए लंबे समय से मौजूद कमी पूरी होती है जो Fly के distributed app platform को तो चाहती थीं लेकिन reliability के लिए managed databases पर निर्भर थीं। Commenters Fly के मौजूदा “automated but unmanaged” Postgres और Supabase के Heroku-style managed approach के बीच trade-offs पर चर्चा करते हैं, जहाँ reliability, HA, monitoring, और scaling मुख्य चिंताएँ हैं। thread में pricing philosophies, distributed SQLite और अन्य Postgres providers जैसे alternatives, और storage durability, network egress controls, तथा PostgREST और row-level security जैसे tools के जरिए business logic को Postgres में कितना धकेलना चाहिए—इन architectural मुद्दों पर भी बात होती है।

साझेदारी और पेशकश

  • Supabase, Fly.io के इन्फ्रास्ट्रक्चर पर एक managed Postgres सेवा चलाएगा, जो Fly की मौजूदा Redis साझेदारी जैसी होगी।
  • Fly का मौजूदा Postgres “automated but unmanaged” है; नया विकल्प स्पष्ट रूप से managed है, जिसमें monitoring, health, और operations Supabase संभालेगा।
  • high-availability सुविधाएँ परीक्षण में हैं; समयसीमा और सटीक feature set पूरी तरह निर्दिष्ट नहीं हैं।

Managed बनाम Unmanaged Postgres

  • Managed: Heroku-शैली के अनुभव के अधिक करीब। आपको connection string मिलता है; provider scaling, health checks, failover, और on-call response संभालता है।
  • आज का Fly Postgres: orchestration tools और clustering दिए जाते हैं, लेकिन users से अपेक्षा होती है कि वे खुद monitoring करें, size तय करें, और failures को remediate करें।
  • कई commenters कहते हैं: core production data के लिए वे नई managed offering चुनेंगे; Fly का अपना Postgres side projects, experiments, या कम-जोखिम वाली सेवाओं के लिए उपयुक्त है।

Reliability, SLA, और Storage Model

  • Fly के ऐतिहासिक uptime और “do it yourself” support posture को लेकर चिंताएँ उठाई गईं; अन्य लोग कहते हैं कि reliability बेहतर हुई है, खासकर Machines पर जाने के बाद।
  • formal SLA के अनुरोध का thread में कोई जवाब नहीं मिलता।
  • Fly volumes host-local NVMe हैं, SAN/network storage नहीं; durability और replication application/database layer पर संभालनी होती है।
  • Fly समय-समय पर volumes का backup लेता है और उन्हें आंतरिक रूप से hosts के बीच migrate कर सकता है, लेकिन volumes को अभी भी non-S3-like माना जाता है और वे स्वाभाविक रूप से “safe” नहीं हैं।

Connection Handling और Networking

  • Supabase-on-Fly setup Supabase के अपने Postgres connection pooler और PostgREST का उपयोग करेगा, Fly के HAProxy का नहीं।
  • Fly Postgres पर HAProxy timeouts की पिछली समस्याओं ने इसमें रुचि पैदा की थी।
  • Fly network के अंदर Supabase होने से unstable outbound IPs और Fly apps तथा external databases के बीच IP allowlisting की समस्याओं से बचाव होता है।

Pricing और Scope

  • शुरुआती संकेत है कि pricing Supabase की मौजूदा plans का अनुसरण करेगी, संभवतः testing के बाद developer-friendly adjustments के साथ।
  • precise resource specs (CPU/RAM), standalone managed-DB pricing, और internal bandwidth charging पर सवाल बने हुए हैं; जवाब अधूरे या अस्पष्ट हैं।

Supabase Platform और Scaling

  • Supabase “just Postgres” है (वर्तमान में AWS पर), जिसकी scaling characteristics RDS जैसी हैं और कुछ बड़े production users का उल्लेख किया गया है।
  • Logical replication समर्थित है और इसे कुछ अन्य managed Postgres providers के मुकाबले एक differentiator के रूप में रेखांकित किया गया है।
  • कुछ लोगों को Supabase की tiered pricing और network restrictions निराशाजनक लगती हैं; अन्य लोग उसके Postgres ecosystem, DX, और add-ons को महत्व देते हैं।

APIs, Business Logic और RLS

  • Supabase प्रदान करता है:
    • Direct Postgres access.
    • Auto-generated REST (PostgREST).
    • Edge/serverless functions.
  • कई commenters चेतावनी देते हैं कि PostgREST के साथ जटिल उपयोग अक्सर business logic को stored procedures (PL/pgSQL या JS extensions) में धकेल देता है, जो कठिन और debug करना मुश्किल हो सकता है।
  • Row-Level Security की इसकी expressiveness के लिए प्रशंसा होती है, लेकिन इसके लिए आलोचना भी होती है:
    • complex/aggregate queries पर performance issues.
    • debugging और testing कठिन, खासकर जब policies में joins हों।
  • मार्गदर्शन: सरल मामलों के लिए ठीक; complex ACLs के लिए पर्याप्त SQL/PL/pgSQL विशेषज्ञता और careful performance tuning चाहिए।

विकल्प और व्यापक संदर्भ

  • कुछ का तर्क है कि नए projects के लिए distributed SQLite (जैसे Turso) या Cloudflare-शैली के “edge + distributed DB” stacks पर Postgres के बजाय विचार किया जा सकता है।
  • प्रति-तर्क:
    • Postgres में richer features हैं (जैसे ltree, logical replication, search tooling जैसे extensions)।
    • Cloudflare Workers में native Postgres equivalent नहीं है; D1 और समान विकल्पों की अपनी trade-offs और maturity संबंधी चिंताएँ हैं।
  • अन्य ecosystems का उल्लेख हुआ: Crunchy Bridge, Neon, k3s + cloudnativepg, Tembo, ParadeDB; thread नोट करता है कि अधिकांश competing managed Postgres offerings ऐतिहासिक रूप से WAL/logical replication expose नहीं करते थे, हालांकि Neon ने हाल ही में CDC जोड़ा है।