आइए, Postgres को खुद होस्ट करके देखें

• Postgres self-hosting जटिल या जोखिमभरा नहीं है, और managed services की तुलना में सस्ता तथा performance tuning के लिए अधिक लचीला तरीका है
• अधिकांश cloud database services, open source Postgres के हल्के संशोधित रूप पर चलती हैं, और वास्तविक अंतर मुख्यतः operational automation के स्तर में होता है
• वास्तविक production उदाहरणों में self-hosted Postgres हज़ारों users और करोड़ों queries को स्थिर रूप से संभालता है, और maintenance समय भी बहुत कम लगता है
• AWS RDS जैसी managed services की बढ़ती कीमतों के कारण, उसी लागत में कहीं अधिक शक्तिशाली server सीधे चलाया जा सकता है
• जिन मध्यम आकार की teams के लिए infrastructure management बहुत जटिल नहीं है, उनके लिए self-hosting लागत और performance दोनों के लिहाज़ से एक व्यावहारिक विकल्प बनता है

---

cloud-केंद्रित narrative में बदलाव

• पहले अधिकांश कंपनियाँ अपने सर्वर पर database सीधे चलाती थीं, और यह कम network latency के कारण तेज़ setup होता था
  • 1980~2000 के दशक में application server और database server अक्सर एक ही physical machine पर होते थे
• Amazon RDS(2009) का लॉन्च backup, patching और monitoring को automate करने वाले आकर्षक प्रस्ताव के रूप में देखा गया
  • शुरुआती दौर में यह dedicated server जैसी कीमत पर operational burden कम कर देता था
• 2015 के बाद cloud adoption तेज़ होने के साथ, infrastructure को खुद manage करना अक्षम माना जाने लगा
  • AWS infrastructure संभाले और developers application logic पर ध्यान दें, यह मॉडल standard बन गया
• 2025 तक RDS की कीमतें काफ़ी बढ़ चुकी हैं, और अब उसी लागत पर कहीं बेहतर specification वाला dedicated server किराए पर लिया जा सकता है
  • उदाहरण: db.r6g.xlarge instance (4 vCPU, 32GB RAM) की कीमत $328 प्रति माह है, जबकि उसी रकम में 32-core·256GB RAM server किराए पर मिल सकता है

managed service की वास्तविक संरचना

• AWS RDS मूल रूप से standard Postgres में AWS-विशेष monitoring और backup systems जोड़कर बनाया गया रूप है
  • इसमें EBS snapshot-आधारित backup, Chef/Puppet/Ansible के ज़रिये configuration management, PgBouncer connection pooling, CloudWatch monitoring, और automatic failover scripts शामिल हैं
• तकनीकी रूप से यह setup बहुत जटिल नहीं है, और इसका मुख्य मूल्य operations automation और initial deployment की सुविधा में है
• समान specification वाले server पर RDS से self-hosting में migration करने पर performance समान रही या बेहतर हुई
  • RDS में सीमित parameters को सीधे adjust कर पाने से performance optimization संभव हुआ

self-hosting की operational complexity

• DigitalOcean के 16 vCPU / 32GB RAM / 400GB disk server पर migration में लगभग 4 घंटे लगे, और उसके बाद स्थिर संचालन की पुष्टि हुई
• high availability products के लिए प्रति माह लगभग 30 मिनट का management समय चाहिए, और कम traffic वाली services को पूरी तरह automate किया जा सकता है
• नियमित management cycle
  • साप्ताहिक(10 मिनट) : backup verification, slow query logs की समीक्षा, disk capacity की जाँच
  • मासिक(30 मिनट) : security updates, backup retention policy की समीक्षा, capacity planning
  • त्रैमासिक(2 घंटे) : monitoring dashboard अपडेट, configuration optimization, recovery test
• incident response की ज़िम्मेदारी सीधे आपकी होती है, लेकिन RDS में भी failures होते हैं और अंततः developers को ही प्रतिक्रिया देनी पड़ती है
• सीधे संचालन करने पर update timing और risk windows को खुद नियंत्रित किया जा सकता है, जिससे stability बनाए रखना आसान होता है

कब self-hosting उपयुक्त नहीं है

• जब शुरुआती developers को तेज़ी से prototype बनाना हो, तब managed service अधिक सुविधाजनक होती है
• बड़ी कंपनियाँ dedicated database engineers रख सकती हैं, या labor cost घटाने के लिए cloud को outsource करना अधिक प्रभावी हो सकता है
• regulated industries (PCI-DSS, HIPAA आदि) में प्रमाणित managed platform का उपयोग आवश्यक हो सकता है

मुख्य configuration points

• memory settings: hardware के अनुसार shared_buffers, effective_cache_size, work_mem, maintenance_work_mem आदि को adjust करना चाहिए
  • उदाहरण: shared_buffers को RAM का 25%, effective_cache_size को 75% पर सेट करना
• connection management: pgbouncer का उपयोग कर connection pooling सेट करें, जो Python asyncio environment में कुशलता से काम करता है
  • max_connections = 200, log_connections = on जैसी basic settings के उदाहरण दिए गए हैं
• storage tuning: NVMe SSD environment में random_page_cost = 1.1, effective_io_concurrency = 200 जैसी settings की जा सकती हैं
  • इससे random read speed बेहतर होती है और query planning optimize होती है
• WAL settings: durability और performance के लिए wal_level = replica, max_wal_size = 2GB, checkpoint_completion_target = 0.9 आदि को adjust किया जा सकता है

निष्कर्ष

• हर infrastructure को खुद चलाने की ज़रूरत नहीं है, लेकिन Postgres उन क्षेत्रों में आता है जहाँ self-hosting एक तर्कसंगत विकल्प है
• यदि आप RDS पर प्रति माह $200 से अधिक खर्च कर रहे हैं, तो non-core database को test server पर ले जाकर आज़माना उपयोगी हो सकता है
• आगे चलकर infrastructure का रूप managed services और self-hosting के मिश्रित hybrid model में विकसित होने की संभावना है
• Postgres को लागत के मुकाबले उच्च दक्षता वाला self-hosting उम्मीदवार माना जा सकता है

[yangeok]

स्टोरेज भी 11 nines की गारंटी देता है, तो क्लाउड इस्तेमाल करने जैसा ऑपरेशन मुश्किल होता है, इसलिए क्लाउड का इस्तेमाल करते हैं haha

[kaydash]

असल में, 3 node क्लस्टर चलाना इतना आसान नहीं होगा।

[GN⁺]

Hacker News की राय

• मैं self-hosting को ज़िम्मेदारी के सवाल के रूप में देखता हूँ
  मैं कुछ SaaS प्रोडक्ट्स को खुद होस्ट कर रहा हूँ, और यह AWS से कहीं सस्ता है जबकि परफ़ॉर्मेंस भी बहुत बेहतर है
  लेकिन client projects में मैं AWS का खर्च देने के लिए मनाता हूँ, क्योंकि इससे hardware availability की ज़िम्मेदारी दूसरी तरफ़ डाली जा सकती है
  जब budget सीमित हो, तब RDS की लागत भारी लगती है. Hetzner पर 3-node Galera cluster को कुछ डॉलर में चलाना कहीं ज़्यादा किफायती है
  लेकिन Cloudflare या SQS जैसी managed services में भी कभी-कभी outage आता है. आखिरकार पूरी तरह स्थिरता कहीं नहीं है

  • मैंने पूछा, “NoNameCMS से Salesforce पर क्यों जा रहे हैं?”, तो जवाब मिला, “अगर Salesforce डाउन हो जाए तो WSJ में ख़बर छपती है.” यह ज़िम्मेदारी टालने की एक व्यावहारिक वजह है
  • client के customer के नज़रिए से “Ikea और Disney भी डाउन हुए थे” जैसी बात काम नहीं आती. आख़िर में मायने सिर्फ़ इतना रखता है कि उनकी अपनी service बंद हुई
  • AWS Serverless PG मौजूद है, तो इसे खुद manage करने की खास वजह नहीं है. low-traffic environment में यह लगभग मुफ़्त जैसा पड़ता है, और security, backup, integration के मामले में काफ़ी बेहतर है
    AWS Aurora Serverless
  • VM स्तर तक ही outsource करके बाकी खुद manage करने वाला समझौता भी संभव है. यह tech stack के operational overhead पर निर्भर करता है
  • 20 साल में मैंने कई clients के self-hosted SQL चलाए हैं, और SQL server एक बार भी डाउन नहीं हुआ
    cloud SQL में उल्टा cost structure काफ़ी जटिल है, और backup configuration तो बस एक बार सेट कर दो, फिर काम ख़त्म

• मैं इस दावे से सहमत नहीं हूँ कि self-hosting ज़्यादातर लोगों के लिए सही विकल्प है
  मेरे हिसाब से यह तभी तर्कसंगत है जब budget बहुत तंग हो, या फिर scale इतना बड़ा हो कि dedicated engineer रखा जा सके
  छोटी कंपनियों के लिए cloud पर छोड़ देना ज़्यादा व्यावहारिक है. setup के बाद महीने में 30~120 मिनट management काफ़ी होता है

  • ज़्यादातर कंपनियाँ cloud इस्तेमाल करके भी infra engineer रखती हैं. “cloud से manpower cost घटती है” यह झूठ है
    Heroku या Render जैसे PaaS को सामान्य developer भी संभाल सकता है, लेकिन वे काफ़ी महंगे हैं
    आख़िरकार अगर application recovery automation नहीं है, तो रात 3 बजे उठना वैसे ही पड़ता है
  • ज़्यादातर services को high availability की ज़रूरत नहीं होती. शनिवार को डाउन हो जाए तो सोमवार को ठीक कर सकते हैं
    अगर यह internal tool है, तो Docker में Postgres जोड़ने में 5 मिनट ही लगते हैं
  • cloud में भी महीने के 1~2 घंटे management time लगता है. self-hosting से बहुत बड़ा फ़र्क नहीं है
  • RDS इस्तेमाल करने पर उल्टा visibility और control कम हो जाता है, इसलिए debugging और मुश्किल होती है
  • असली मुद्दा efficiency नहीं, बल्कि समस्या आने पर डाँट किसे पड़ेगी यह है. cloud में blame shift करना आसान होता है

• ‘managed database’ की परिभाषा ही उलझी हुई है
  मेरे लिए बुनियादी शर्तें हैं automatic backup, index optimization, multi-datacenter failover, point-in-time recovery, slow query analysis, storage forecasting
  अगर यह सब monthly fee में मिलता है, तो self-hosting पर बहस का मतलब ही नहीं रह जाता

  • समस्या यह है कि specialist staff रखना पड़ता है. अगर Postgres संभालने वाला छुट्टी पर चला जाए, तो bus factor की समस्या पैदा होती है
    आख़िरकार दो लोग रखने पड़ते हैं, और फिर काम कम होने पर वे गैर-ज़रूरी सुधारों में लगकर 6 महीने भी बर्बाद कर सकते हैं
  • self-hosting की असली वजह आखिरकार latency है. backup या analysis तो बुनियादी चीज़ें हैं, लेकिन सबसे तेज़ नतीजा खुद बनाकर ही मिलता है
  • setup सही हो तो backup या multi-region failover भी automate किया जा सकता है
  • मैं वही services self-host करता हूँ जिनके लिए रात 3 बजे फ़ोन नहीं आएगा. logs या internal analytics जैसी चीज़ें ठीक हैं, लेकिन DB कभी नहीं
  • Yugabyte open source इन फ़ीचर्स का ज़्यादातर हिस्सा कवर कर देता है

• managed DB, VPS के मुकाबले बहुत महंगा है
  मैंने convenience premium की उम्मीद की थी, लेकिन असल में यह कई गुना ज़्यादा महंगा निकला. इसलिए बड़े projects के अलावा मैं इसका इस्तेमाल नहीं करता

  • वे आपको यह यक़ीन दिलाते हैं कि आप खुद नहीं कर सकते, और फिर इसी बीच कीमतें लगातार बढ़ाते रहते हैं. migration करने की skill न हो तो dependency बन जाती है

• लेख में high availability (HA) वाला हिस्सा कमज़ोर है. सिर्फ़ WAL settings से बात पूरी नहीं होती. replication महंगा पड़ता है

• समझ नहीं आता कि HN पर Postgres को इतना बढ़ा-चढ़ाकर क्यों देखा जाता है
  MongoDB की तरह automatic failover वाला HA cluster आसानी से बनाने का तरीका नहीं है. जानना चाहता हूँ कि production services में लोग इसे कैसे सुलझाते हैं

  • PostgreSQL community भी इस समस्या को पहचानती है. वे MongoDB की built-in replication stability से ईर्ष्या करती हैं
    संबंधित चर्चा: PostgreSQL mailing list
  • अगर Kubernetes इस्तेमाल कर रहे हैं, तो CloudNativePG वस्तुतः standard HA solution है
  • SQL ecosystem असली HA की बजाय तेज़ recovery (Disaster Recovery) का ज़्यादा आदी है
    व्यवहार में सभी connections टूट जाते हैं, cache reset हो जाता है, और upgrade के समय service interruption अनिवार्य होती है
    Oracle RAC ही अपवाद है, और PostgreSQL उस तरह की architecture नहीं है. YugabyteDB कुछ हद तक विकल्प है
    ज़्यादातर apps कुछ घंटों के downtime को स्वीकार कर लेते हैं. सिर्फ़ बड़ी कंपनियाँ ही इस जटिल automation का खर्च उठा सकती हैं
  • सबसे आम तरीका Patroni इस्तेमाल करना है. इसे आसान रखना हो तो Autobase इस्तेमाल करें
    Kubernetes environment में CloudNativePG भी अच्छा है.
    pg_auto_failover सरल है, लेकिन इसकी सीमाएँ हैं
  • सच तो यह है कि ज़्यादातर businesses को ऐसी जटिल HA की ज़रूरत ही नहीं होती. लागत के मुकाबले फ़ायदा कम है

• Autobase को देखें तो यह self-hosting के लिए ज़रूरी कामों को अपने-आप संभाल देता है

  • README देखकर लगा कि connection pooling शायद इसके दायरे से बाहर है
  • जानना चाहूँगा कि क्या यह दूसरे self-hosted PaaS के साथ भी अच्छी तरह integrate होता है. लगता है यह Docker container के रूप में चलता है
  • शानदार project है, इसके लिए धन्यवाद

• 15 साल से मैं Postgres को हमेशा self-hosted रूप में इस्तेमाल करता आया हूँ, और लगभग कभी समस्या नहीं हुई
  एकमात्र चिंता तब होती थी जब ORM upgrade के हिसाब से PG version migration करना पड़ता था. सावधानी से system administration करके इसे संभाला जा सकता था

• मैंने Fly.io पर unmanaged Postgres खुद चलाया था, और बहुत परेशान हुआ
  nodes बार-बार मर जाते थे, इसलिए repmgr से manual recovery करनी पड़ती थी, और आखिरकार मैंने internal wiki में पूरा procedure लिख दिया
  cluster का मक़सद high availability है, तो फिर zombie primary को अपने-आप handle क्यों नहीं करता, यह समझ नहीं आया
  आख़िर में मैं managed Postgres पर चला गया, और outage के समय किसी दूसरे के उसे संभाल लेने की सुविधा सच में बहुत राहत देती है

  • अब मैं Fly का Managed Postgres इस्तेमाल कर रहा हूँ

• इस thread में बहुत-सी टिप्पणियाँ scale, workload, staffing, time, business stage, scalability requirements जैसे वास्तविक कारकों को नज़रअंदाज़ करती हैं
  self-hosting सही भी हो सकता है, ग़लत भी, लेकिन चर्चा ज़रूरत से ज़्यादा सरल बना दी गई है

  • engineers अक्सर ऐसे कारकों पर लगभग ध्यान नहीं देते, और boss से approval मिल सके ऐसा सबसे महंगा solution चुनने की प्रवृत्ति रखते हैं

[sinbumu]

डेवलपर्स की चिंता में शायद यह भी अहम होगा कि ऐसी चीज़ों को self-hosting करने पर उस मेहनत को मान्यता मिलेगी या नहीं। अगर cloud cost ज़्यादा भी आए, लेकिन self-hosting से की गई cost saving को मान्यता न मिले, तो बस cloud service इस्तेमाल करके कवर कर लेना और हैंडल करने वाले एरिया को कम करना ही ज़्यादा आसान लगेगा।