Supabase द्वारा प्रबंधित Fly Postgres
(supabase.com)- Supabase और Fly.io के managed Postgres सहयोग का उद्देश्य Fly इंफ्रास्ट्रक्चर पर Supabase डेटाबेस फीचर्स उपलब्ध कराना था, लेकिन यह अब बंद कर दिया गया है
- इस सेवा का लक्ष्य Fly.io के 37 से अधिक locations में चलने वाले edge computing वातावरण में Postgres को तैनात करना था, ताकि Fly applications और डेटाबेस को एक-दूसरे के करीब रखा जा सके
- फीचर सेट में 40 से अधिक extensions, pgvector, Supavisor, daily backups, point-in-time recovery, branching, observability, migrations, dashboard, और REST·GraphQL auto-generated APIs शामिल थे
- शुरुआती deployment को धीरे-धीरे रोलआउट किया जाना था, और billing, support handoff, internal training जैसी कंपनियों के बीच integration tasks के साथ शुरुआती testers के bugs ठीक किए जाने बाकी थे
- जहां Fly का मौजूदा Postgres user-managed और non-managed था, वहीं Fly Postgres एक managed service था जिसमें scaling, backups, replication, और upgrades की जिम्मेदारी Supabase लेता था
रिलीज़ स्थिति और सेवा का दायरा
- Fly Postgres अब बंद कर दिया गया है; अधिक जानकारी deprecation announcement में देखी जा सकती है
- Supabase और Fly.io ने Fly इंफ्रास्ट्रक्चर पर चलने वाली managed Postgres सेवा के रूप में Fly Postgres लॉन्च किया था
- डेटाबेस Fly.io के edge computing platform पर चलता था, और Fly.io के 37 से अधिक locations में से चुनकर शुरुआत की जा सकती थी
- Fly पर deploy की गई data-intensive applications, उसी इंफ्रास्ट्रक्चर में डेटाबेस रखने के कारण कम latency की उम्मीद कर सकती थीं
Supabase managed Postgres की विशेषताएँ
- Fly Postgres, Supabase managed database से अपेक्षित मुख्य फीचर्स Fly वातावरण में उपलब्ध कराता था
- Supabase Postgres के 40 से अधिक extensions
- pgvector आधारित Vector/AI workloads का समर्थन
- Supabase का Postgres connection pooler Supavisor
- daily backups और point-in-time recovery
- branching, observability, migrations
- डेटाबेस प्रबंधन के लिए dashboard
- auto-generated Data API
- PostgREST का उपयोग करने वाला REST API
- pg_graphql का उपयोग करने वाला GraphQL API
क्रमिक रोलआउट और शुरुआती परीक्षण
- लॉन्च gradual rollout के रूप में किया जाना था
- कंपनियों के बीच integration में billing, support handoff, और Supabase कर्मचारियों की training जैसे कार्य शामिल थे
- कुछ शुरुआती testers के साथ सत्यापन चल रहा था, और कुछ bugs अभी ठीक किए जाने बाकी थे
- टेस्ट में शामिल होने के इच्छुक लोग waitlist में पंजीकरण कर सकते थे
- अगले महीने अधिक testers जोड़ने की योजना थी, और data safety पर भरोसा होने के बाद आगे की रिलीज़ समय-सारिणी साझा की जानी थी
managed और non-managed Postgres में अंतर
- Fly का मौजूदा Postgres ऑफर non-managed था
- users को scaling, point-in-time backups, replication, major version upgrades आदि खुद संभालने पड़ते थे
- Supabase द्वारा संचालित Fly के managed Postgres में users एप्लिकेशन बनाने पर अधिक ध्यान दे सकते थे
- यह managed service Fly extension API से बनाई गई थी
- यही API Fly Redis में भी उपयोग होती है
- testers
fly extensionsकमांड से Postgres डेटाबेस बना सकते थेfly extensions supabase create
- सेवा स्थिर होने पर इसे
postgresnamespace से बदलने की योजना थीfly postgres create
Fly Machines आधारित इम्प्लीमेंटेशन
- Fly Postgres, Fly machines के ऊपर बनाया गया था
- Machines हल्के Firecracker VM हैं, और Machines API एप्लिकेशन lifecycle पर सूक्ष्म नियंत्रण देता है
- Machines निष्क्रिय अवस्था में suspend हो सकती हैं और नया अनुरोध आने पर कुछ सेकंड में फिर शुरू हो सकती हैं
- Supabase ने Fly API के साथ interaction को सरल बनाने के लिए fly-admin नाम का TypeScript wrapper बनाया
- क्योंकि Supabase Postgres के साथ कुछ अतिरिक्त सेवाएँ भी बंडल करता है, इसलिए Fly Machines API को भेजने के लिए एक single Docker image तैयार की गई
- मौजूदा build process Packer से AWS के लिए AMI बनाती थी, और उसी pipeline के एक हिस्से का पुन: उपयोग करके All In One Image बनाया गया
- All In One Image में एक single Docker container के अंदर Supabase project चलाने के लिए आवश्यक सभी सेवाएँ शामिल थीं
multi-cloud की ओर बदलाव
- इस लॉन्च के साथ Supabase आधिकारिक रूप से multi-cloud बन गया
- Supabase ने multi-cloud परिवर्तन को सरल रखने के लिए AWS की managed services से जानबूझकर दूरी बनाई
- हर cloud provider के मूल primitives काफी अलग होते हैं, इसलिए यह परिवर्तन सीधा नहीं होता
- Fly Machines unused VM को suspend करके कुछ सेकंड में पारदर्शी रूप से resume करने की सुविधा देता है
- इससे inactive databases को pause करना आसान हो जाता है
- AWS में इसे सीधे हासिल करने वाला कोई primitive नहीं है
- दूसरी ओर Fly में AWS के कुछ primitives नहीं हैं, इसलिए workaround की जरूरत पड़ती है
- Fly Machines में network-attached storage नहीं है
- Supabase, Fly volumes के डेटा को अस्थायी डेटा की तरह मानता है
- Fly पर चलने वाले सभी projects के लिए WAL-G से physical backups किए जाते हैं
- डेटाबेस changes लगातार S3 पर stream किए जाते हैं
- अगर host या volume को नुकसान हो जाए, तो नवीनतम S3 डेटा से project को नए Fly host पर restore किया जाता है
संचालन निगरानी और image deployment
- AWS में host समस्याओं का पता लगाने के लिए AWS Health events प्राप्त किए जाते हैं
- Fly में Machine logs को fly-log-shipper के माध्यम से Logflare तक भेजा जाता है
- Supabase, All In One image को AWS container registry के साथ-साथ Fly Docker registry में भी प्रकाशित करता है
- Fly Docker registry में image प्रकाशित करने से Fly पर project शुरू करते समय reliability और performance बेहतर होती है
Fly extensions और authentication integration
- Fly, platform विस्तार के लिए Extensions API प्रदान करता है
- Supabase ने users और projects को provision करने के लिए API में कुछ routes जोड़े
- Fly users अपने मौजूदा Fly credentials से Supabase dashboard तक पहुँच सकते थे
- Supabase API, user authentication के लिए Fly के साथ OAuth flow शुरू करता है
- API integration आसान बनाने के लिए Supabase Auth टीम ने Fly OAuth provider बनाया
बाकी चुनौतियाँ
- Supabase, Fly टीम के साथ मिलकर कुछ operational चुनौतियों पर काम कर रहा था
-
network restrictions support
- network restrictions फीचर के काम करने के लिए container को connecting client का सही IP मिलना चाहिए
- मौजूदा configuration में container को client IP की जगह Fly proxy IP दिखता है
- connections, Proxy protocol expose करने वाले Fly proxy से होकर गुजरते हैं
- Postgres इस जानकारी का सीधे उपयोग नहीं कर सकता, और Supabase इस पर विचार कर रहा था कि Supavisor को proxy-protocol aware कैसे बनाया जाए
-
Fly internal backups
- Fly अभी managed Blob storage उपलब्ध नहीं कराता, इसलिए Fly projects के backups AWS S3 पर किए जाते हैं
- इस तरीके से clouds के बीच bandwidth cost पैदा होती है
- Fly, Blob Storage पर काम कर रहा है
शुरुआत कैसे करें और कीमत
- preview के लिए आवेदन preview form में किया जा सकता था
- जब किसी organization को allowlist में जोड़ दिया जाता, तब वह docs के Quickstart से शुरुआत कर सकती थी
- हर Fly organization को 1 मुफ्त project मिल सकता था
- billing से जुड़ी जानकारी अभी तैयार की जा रही थी, लेकिन कीमतें मौजूदा Supabase pricing की तुलना में बहुत अधिक बदलने की उम्मीद नहीं थी
1 टिप्पणियां
Hacker News की राय
मैं Supabase का CEO हूँ। Fly का मौजूदा Postgres unmanaged है, इसलिए हम Fly के साथ मिलकर एक managed service चलाने पर काम कर रहे हैं
यह वही मॉडल है जो Fly Redis में Upstash टीम के साथ है: https://fly.io/docs/reference/redis/
अभी हम testers के साथ high availability features deploy कर रहे हैं और कोई पक्का timeline नहीं है, लेकिन Fly टीम के साथ इसे जितनी जल्दी हो सके आगे बढ़ाएंगे
मैंने कम ही सुना है कि किसी दूसरी कंपनी की non-hosted service का hosted version manage करने के लिए कोई बाहरी कंपनी आकर collaborate करे
मैंने पहले Supabase देखा था, लेकिन basic REST API कैसे बनता है यह समझ नहीं आया था
Table बनाने पर interaction के लिए API अपने-आप generate हो जाता है, यह अच्छा लगता है, लेकिन फिर business logic कहाँ रखना चाहिए, यह नहीं समझ आया
Edge Functions भी देखे, पर examples काम process करने जैसे ज्यादा लगे, इसलिए साफ नहीं था कि उन्हें इसी use case के लिए इस्तेमाल करना है या नहीं; लगा जैसे कोई सरल बात छूट रही है
REST API joins जैसी data aggregation के लिए काफी सुविधाजनक है, लेकिन जैसे ही transactions जैसी चीज़ें चाहिए होने लगती हैं, यह अटकने लगता है
role-based access control के लिए row-level security (RLS) भी झंझट वाला था और developer experience कमज़ोर लगा
अगर DB requirements सरल हैं तो REST API बहुत convenient है, लेकिन अगर complex चीज़ें plan कर रहे हैं तो PL/pgSQL सीखना या normal DB connection इस्तेमाल करना बेहतर है
ज्यादातर मामलों में पहला विकल्प काफी है, और दूसरे व तीसरे विकल्प को जरूरत पड़ने पर इस्तेमाल होने वाले extra tools समझना बेहतर है
कई use cases में logic को SQL stored procedures में रखा जा सकता है, और PostgreSQL में JS या Python stored procedures भी संभव हैं
हालांकि logic code को सामान्य CI/CD containers या functions के रूप में deploy करने में developer experience बेहतर होता है, और cost trade-off के आधार पर दोनों तरीके खूब इस्तेमाल होते हैं
Supabase Deno serverless functions recommend करता है, लेकिन web project हो तो अधिकतर लोग Cloudflare पर Node functions deploy करना ज्यादा पसंद करेंगे
आखिरकार target customers वे लगते हैं जो 99% logic JS frontend में रखना चाहते हैं, और backend से सिर्फ CRUD और authentication कराना चाहते हैं
उस हिस्से को हमने Postgres WAL-based event system बनाकर callback system की तरह handle किया
हमने Elixir के लिए एक छोटी library भी बनाई, जो मूल रूप से Supabase Realtime को fork करके शुरू हुई थी: https://github.com/cpursley/walex
हाल में हमने WalEx में events को webhooks या EventRelay तक भेजने के लिए configure करने की सुविधा जोड़ी है, ताकि Elixir जानना जरूरी न हो
हम Next.js इस्तेमाल कर रहे हैं, इसलिए DB calls का काफी हिस्सा Next serverless functions के अंदर है
हालांकि DB के जितना करीब हो सके रखने के लिए कुछ logic को Supabase functions में ले जाने पर भी विचार करेंगे, लेकिन अभी Deno में जाना नहीं चाहते थे
server से Supabase access करते समय Supabase client द्वारा इस्तेमाल किए जाने वाले PostgREST features इस्तेमाल कर सकते हैं, या सामान्य
pglibrary से सीधे Postgres access कर सकते हैंइस पर migrate करने को लेकर उत्साहित हूँ। Fly.io और Fly Postgres पर Booklet बनाते हुए हमने app को distributed तरीके से design किया है: https://www.contraption.co/essays/booklet-architecture/
सबसे बड़ी समस्या Fly Postgres setup था। खासकर Fly Postgres के सामने HAProxy रखता है और 30-minute connection limit लगाकर connections बार-बार काटता रहता है: https://community.fly.io/t/postgresql-connection-issues-have...
यह manage करने योग्य समस्या होनी चाहिए, लेकिन connection termination का behavior docs से मेल नहीं खाता और अजीब लगता है, इसलिए यह लगातार unstable रहता है
जानना चाहूँगा कि नए Postgres के front में भी वही HAProxy होगा या नहीं
https://supabase.com/blog/supavisor-postgres-connection-pool...
https://postgrest.org/
आज Fly docs में यह देखा और लगा कि शायद HN पर miss कर दिया, लेकिन यह नया ही निकला
दूसरी बात जो दिमाग में आई, वह यह कि sidebar में Postgres by Fly और Postgres by Supabase का साथ-साथ होना अजीब है
कोई साफ comparison भी नहीं दिखा, इसलिए अगर Fly पर app deploy कर रहे हों और Postgres चाहिए हो तो क्या इस्तेमाल करें, यह confusing है
निजी तौर पर अगर Fly पर DBMS चाहिए हो तो मैं LiteFS distributed SQLite इस्तेमाल करूँगा, और अगर Postgres चाहिए हो तो Fly और Supabase का फर्क असल में unmanaged बनाम managed है
बहुत अच्छा। Supabase की network restriction सेटिंग मुझे खास पसंद नहीं आई थी: https://supabase.com/docs/guides/platform/network-restrictio...
पहले जब देखा था, तो याद है कि Fly ऐप का IP Supabase को expose करने और Supabase को उसी IP तक lock करने में कुछ अजीब समस्याएँ थीं
Supabase का सच में Fly network के अंदर आना शानदार है
यह Fly.io networking docs में भी लिखा है
सुना है कि prototype से आगे जाने पर Supabase में scalability issues हैं, जानना चाहूँगा कि production experience वाला कोई इस पर बता सकता है या नहीं
आप खास तौर पर किन समस्याओं की बात कर रहे हैं?
Fly.io की तरफ से Joshua हूँ। इस integration पर कोई सवाल हो तो जवाब दूँगा
कुछ side projects में इस्तेमाल कर रहा हूँ, लेकिन अभी बड़े projects में नहीं
अगली चीज़ जिसकी उम्मीद है वह Blob storage है, क्योंकि state वाली चीज़ें मैं मूलतः managed रूप में इस्तेमाल करना चाहता हूँ, इसलिए अच्छा है कि उस पर भी काम चल रहा है
नए Postgres offering की pricing पर कोई details हैं क्या?
अभी Fly पर एक बड़ा DB चला रहे हैं और managed PostgreSQL ढूँढ रहे हैं, इसलिए यह खबर बहुत अच्छी लगी
हम पूरी तरह Elixir team हैं, इसलिए timing इससे बेहतर नहीं हो सकती थी
“Fly machines don't have network-attached storage, so we treat any data in Fly volumes as ephemeral.”
मैंने AWS इस्तेमाल नहीं किया है और network-attached storage के बारे में भी ज्यादा नहीं जानता, इसलिए जानना चाहता हूँ कि Fly volumes और दूसरे providers के network-attached storage में ठीक-ठीक फर्क क्या है
लगता था कि Fly volume बनाने के बाद उसे उसी region के दूसरे server पर move किया जा सकता है, तो technically क्या वह network-attached storage नहीं हुआ?
internally हम volume को एक physical host से दूसरे physical host पर move कर सकते हैं; तरीका काफी दिलचस्प है, लेकिन अभी इसे public तौर पर ज्यादा expose नहीं किया है
इस साल इसे और सामने लाने की योजना है
Fly Volumes का regular backup off-network block storage में हो रहा है, और इस बारे में भी जल्द और announcements होंगे
मूल बात यह समझनी चाहिए कि Fly Volumes SAN storage नहीं हैं, और S3 जैसी inherently reliable storage भी नहीं हैं
Fly Machines के अंदर वे एक simple ext4 filesystem की तरह दिखते हैं, और reliability, durability, replication चाहिए तो application layer में provide करनी होगी
Fly Postgres read replica cluster की तरह काम करता है, और जरूरत पड़ने पर कोई भी replica write leader की भूमिका ले सकता है, इसलिए यह तरीका सही बैठता है
single-node Postgres cluster बनाने की कोशिश करने पर console में बड़ा लाल warning दिखाने की वजह भी यही है
आने वाली कुछ quarters में reliability और performance spectrum पर नए विकल्प ला सकते हैं, लेकिन iSCSI जैसी approach से सिर्फ block device expose करने वाली SAN drive खुद operate करने वाला model शायद नहीं होगा
इन दोनों companies के pricing models मुझे सच में पसंद नहीं हैं
एक छोर पर Supabase है, जो Vercel जैसे developer platform वाला tiered product है, जहाँ structure ऐसा है कि actual usage से ज्यादा pay करना पड़ता है
दूसरे छोर पर Fly है, जहाँ Lambda की तरह second, memory और CPU unit के हिसाब से जरूरत से ज्यादा granular pricing है, जिससे शायद बहुत कम pay करके performance degradation झेलना पड़े
Cloudflare Workers जैसी चीज़ मौजूद है, तो समझ नहीं आता कि इन दोनों में से किसी को क्यों चुनें। लोग अब भी scaling की चिंता क्यों करना चाहते हैं?
Cloudflare के असली Postgres देने की संभावना भी कम लगती है। Cloudflare की philosophy यह है कि जो कुछ deploy हो वह पूरी दुनिया में deploy हो, जबकि relational database एक single server को source of truth बनाने पर मजबूर करता है
हाँ, अगर यह गलत साबित हो तो खुशी होगी
Fly की monthly pricing काफी straightforward है और Lambda जैसी बिल्कुल नहीं है। उल्टा, दोनों में Cloudflare Workers का pricing model Lambda के ज्यादा करीब है