Kubernetes पर PostgreSQL या मैनेज्ड: असली लागत

संक्षिप्त उत्तर: कुछ दर्जन गीगाबाइट के एक ही डेटाबेस वाले SME एप्लिकेशन के लिए, एक मैनेज्ड डेटाबेस (OVHcloud, Scaleway, Amazon RDS) की लागत प्रति माह 25 से 120 € के बीच रहती है और यह आपको बैकअप तथा वर्शन अपग्रेड की ऑन-कॉल ज़िम्मेदारी से मुक्त कर देता है। आपके Kubernetes क्लस्टर में CloudNativePG की लागत नोड्स और स्टोरेज जितनी होती है — अक्सर 2 से 3 गुना कम — लेकिन PITR, फेलओवर और मेजर अपग्रेड की ज़िम्मेदारी आप पर आ जाती है। सही मानदंड कीमत नहीं है: यह है कि रात 3 बजे डेटाबेस रिस्टोर कर सकने वाले कितने लोग आपके पास हैं।

यह वही सवाल है जो हर बार तब उठता है जब कोई टीम अपना एप्लिकेशन Kubernetes पर माइग्रेट कर चुकी होती है। एप्लिकेशन पॉड्स stateless हैं, डिप्लॉयमेंट साफ़-सुथरा है, CI इमेज पुश करती है — और बचा रहता है वही PostgreSQL डेटाबेस जो अब भी 2021 की किसी VM पर चल रहा है, एक cron में pg_dump के साथ, और अठारह महीनों से किसी ने रिस्टोर टेस्ट नहीं किया।

तीन संभावित विकल्प, और वह जिसे छोड़ देना चाहिए

दरअसल परिदृश्य दो नहीं, तीन हैं।

1. क्लस्टर के भीतर PostgreSQL, किसी ऑपरेटर द्वारा संचालित — CloudNativePG, Percona Operator, Zalando postgres-operator। ऑपरेटर रेप्लिकेशन, फेलओवर, सतत बैकअप और माइनर अपडेट संभालता है।
2. किसी प्रदाता के पास मैनेज्ड डेटाबेस — OVHcloud Databases for PostgreSQL, Scaleway Database for PostgreSQL, Amazon RDS / Aurora, और सर्वरलेस विकल्पों के लिए Neon या Supabase।
3. बिना ऑपरेटर के क्लस्टर में PostgreSQL — हाथ से लिखा हुआ कोई StatefulSet, या उससे भी बुरा, Bitnami का Helm chart जिसे replicaCount: 1 पर छोड़ दिया गया हो और बैकअप «बाद में कर लेंगे» की सूची में पड़े हों।

परिदृश्य 3 को छोड़ देना चाहिए। इसलिए नहीं कि PostgreSQL कंटेनर में ठीक से नहीं चलता — वह बहुत अच्छा चलता है — बल्कि इसलिए कि प्रोडक्शन में डेटाबेस की असली कीमत जिन चीज़ों से बनती है (WAL आर्काइविंग, रेप्लिका का प्रमोशन, किसी निश्चित समय-बिंदु तक रिस्टोर), ठीक वही एक नंगा StatefulSet नहीं करता। और यह बात किसी घटना वाले दिन ही पता चलती है।

मैदानी नियम: अगर टीम में कोई भी «हमारा RPO क्या है, और आख़िरी बार हमने उसे कब जाँचा था?» का जवाब नहीं दे सकता, तो मुद्दा होस्टिंग का चुनाव नहीं है, बल्कि रिस्टोर प्रक्रिया का न होना है।

CloudNativePG: ऑपरेटर आपके लिए क्या करता है

CloudNativePG मूल रूप से EDB द्वारा विकसित PostgreSQL ऑपरेटर है, जिसे जनवरी 2025 में CNCF के sandbox प्रोजेक्ट के रूप में स्वीकार किया गया और फिर 2026 में incubating स्तर पर पहुँचा दिया गया। आज यह Kubernetes-नेटिव पक्ष का मानक है: न Patroni, न बाहरी etcd — प्राइमरी का चुनाव स्वयं Kubernetes API पर आधारित होता है।

इंस्टॉलेशन एक ही कमांड में हो जाता है (चलाने से पहले रिपॉज़िटरी पर मौजूदा वर्शन नंबर जाँच लें):

kubectl apply --server-side -f \
  https://raw.githubusercontent.com/cloudnative-pg/cloudnative-pg/release-1.27/releases/cnpg-1.27.0.yaml
kubectl get deploy -n cnpg-system cnpg-controller-manager

तीन इंस्टेंस वाला एक क्लस्टर, जिसमें S3-संगत बकेट (यहाँ Scaleway Object Storage, OVHcloud का समकक्ष भी इसी तरह काम करता है) पर सतत आर्काइविंग हो, इस तरह परिभाषित होता है:

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: app-db
  namespace: production
spec:
  instances: 3
  imageName: ghcr.io/cloudnative-pg/postgresql:17.6
  storage:
    size: 50Gi
    storageClass: scw-bssd
  walStorage:
    size: 10Gi
  postgresql:
    parameters:
      shared_buffers: 512MB
      max_connections: "200"
  resources:
    requests:
      cpu: "1"
      memory: 2Gi
    limits:
      memory: 2Gi
  backup:
    retentionPolicy: "30d"
    barmanObjectStore:
      destinationPath: s3://mon-bucket-backups/app-db
      endpointURL: https://s3.fr-par.scw.cloud
      s3Credentials:
        accessKeyId:
          name: backup-creds
          key: ACCESS_KEY_ID
        secretAccessKey:
          name: backup-creds
          key: ACCESS_SECRET_KEY
      wal:
        compression: gzip

दो बातें रेखांकित करने लायक हैं।

अलग walStorage। WAL को डेटा डायरेक्टरी से अलग वॉल्यूम पर रखने से यह टलता है कि आर्काइविंग का जाम मुख्य वॉल्यूम भर दे और राइट्स रुक जाएँ। सेल्फ-होस्टेड डेटाबेस पर यही सबसे आम खराबी है।

barmanObjectStore = PITR। ऑब्जेक्ट स्टोरेज पर WAL की सतत आर्काइविंग ही वह चीज़ है जो किसी निश्चित समय-बिंदु तक रिस्टोर संभव बनाती है। इसके बिना आपके पास केवल बेस बैकअप होते हैं, यानी RPO दो बैकअप के बीच के अंतराल के बराबर — आमतौर पर 24 घंटे।

किसी निश्चित समय-बिंदु तक रिस्टोर करना

रिस्टोर मौजूदा क्लस्टर को नहीं बदलता: यह आर्काइव से एक नया क्लस्टर बनाता है। यह ज़्यादा सुरक्षित है, और स्टेजिंग में बिना जोखिम के परखा जा सकता है।

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: app-db-restore
spec:
  instances: 1
  storage:
    size: 50Gi
  bootstrap:
    recovery:
      source: app-db-archive
      recoveryTarget:
        targetTime: "2026-11-06 14:25:00.00000+01"
  externalClusters:
    - name: app-db-archive
      barmanObjectStore:
        destinationPath: s3://mon-bucket-backups/app-db
        endpointURL: https://s3.fr-par.scw.cloud
        s3Credentials:
          accessKeyId:
            name: backup-creds
            key: ACCESS_KEY_ID
          secretAccessKey:
            name: backup-creds
            key: ACCESS_SECRET_KEY
        wal:
          maxParallel: 8

इस अभ्यास को तिमाही में एक बार अपने कैलेंडर में डाल लें। जो रिस्टोर कभी किया ही न गया हो, वह बैकअप नहीं, बस एक इरादा है।

मेजर अपग्रेड आपकी ही ज़िम्मेदारी रहते हैं

CloudNativePG माइनर अपडेट (17.5 → 17.6) को रोलिंग रीस्टार्ट से संभालता है: पहले रेप्लिका, फिर प्राइमरी का स्विचओवर, जिसमें कुछ सेकंड की कटौती होती है। PostgreSQL 17 से 18 पर जाना अलग मामला है: वर्शन 1.26 से ऑपरेटर घोषणात्मक pg_upgrade चला सकता है, लेकिन इसमें सेवा बाधित होती है और रोलबैक योजना चाहिए। PostgreSQL के सपोर्ट कैलेंडर को ध्यान में रखें: हर मेजर वर्शन पाँच साल तक मेंटेन होता है, जिसका मतलब है कि हर तीन से चार साल में अधिकतम एक मेजर माइग्रेशन आपको करना ही पड़ेगा।

मैनेज्ड डेटाबेस असल में क्या ख़रीदता है

मैनेज्ड सेवा कंप्यूट पावर नहीं बेचती, वह बचाया गया ऑन-कॉल समय बेचती है। ठोस रूप से, फ़्रांस में सबसे अधिक मिलने वाले तीन प्रदाताओं के पास क्या शामिल है:

आख़िरी पंक्ति की तीन सीमाएँ ही असली बाधाएँ हैं, कीमत से कहीं पहले। कोई SUPERUSER नहीं, यानी श्वेतसूची से बाहर कोई एक्सटेंशन नहीं। अगर आपके एप्लिकेशन को pg_cron, timescaledb या किसी इन-हाउस एक्सटेंशन की ज़रूरत है, तो अनुबंध करने से पहले इसकी जाँच करें: सेल्फ-होस्टिंग पर वापस लौटने का यह नंबर एक कारण है।

दूसरा बिंदु जिसे अक्सर नज़रअंदाज़ किया जाता है: नेटवर्क लेटेंसी। आपके क्लस्टर के उसी क्षेत्र में मौजूद मैनेज्ड डेटाबेस भी आमतौर पर प्रति क्वेरी एक नेटवर्क राउंड-ट्रिप जोड़ता है। जो API प्रति पेज 40 SQL क्वेरी करती है — और ख़राब कॉन्फ़िगर किए गए ORM के साथ यह जल्दी हो जाता है — वहाँ यह बारीकी दिखने लगती है। यह नतीजा निकालने से पहले कि डेटाबेस धीमा है, pg_stat_statements से माप लें।

बिल, मद दर मद

मूल्य-सूचियाँ बदलती रहती हैं; परिमाण के क्रम उतने नहीं बदलते। निर्णय के समय हमेशा OVHcloud, Scaleway और AWS के सार्वजनिक पृष्ठ जाँच लें, पर सोचिए इसी ढाँचे में।

मैनेज्ड विकल्प, 50 GB का डेटाबेस, 2 vCPU / 8 GB RAM, सेकंडरी नोड सहित:

• प्राइमरी इंस्टेंस और उसका रेप्लिका: मुख्य मद, घंटे के हिसाब से बिल;
• स्टोरेज, गीगाबाइट-माह के हिसाब से;
• शामिल रिटेंशन से आगे के बैकअप;
• आउटबाउंड ट्रैफ़िक, यदि डेटाबेस एप्लिकेशन वाले क्षेत्र में न हो।

इस आकार पर व्यवहार में OVHcloud या Scaleway पर 60 से 150 € प्रति माह की सीमा में रहते हैं, और AWS पर Multi-AZ में काफ़ी ज़्यादा, क्योंकि स्टोरेज और प्रोविज़न्ड IOPS अलग से बिल होते हैं।

CloudNativePG विकल्प, वही आकार, तीन इंस्टेंस:

• कोई लाइसेंस नहीं: ऑपरेटर Apache 2.0 के तहत है;
• आपके मौजूदा नोड्स पर खपत होने वाला CPU/RAM हिस्सा — अगर आपके क्लस्टर में पहले से गुंजाइश है, तो सीमांत लागत कम है, वरना एक अतिरिक्त नोड जोड़िए;
• तीन परसिस्टेंट डेटा वॉल्यूम और तीन WAL वॉल्यूम, ब्लॉक स्टोरेज प्रदाता द्वारा गीगाबाइट-माह के हिसाब से;
• बैकअप के लिए ऑब्जेक्ट स्टोरेज: कुछ सौ गीगाबाइट कंप्रेस्ड WAL के लिए महीने में कुछ यूरो।

अक्सर इंफ्रास्ट्रक्चर लागत 25 से 60 € प्रति माह के बीच आती है। दिखने वाला अंतर साफ़ है — लेकिन यह जानबूझकर सबसे महँगी मद को छोड़ देता है।

वह मद जिसका हिसाब कोई नहीं लगाता

मासिक बचत के सामने संचालन की लागत रखिए: मेट्रिक्स की निगरानी (रेप्लिकेशन लैग, WAL आर्काइविंग की सफलता दर, वॉल्यूम भरना), तिमाही रिस्टोर टेस्ट, हर तीन साल में मेजर माइग्रेशन, और किसी घटना के समय एक सक्षम व्यक्ति की उपलब्धता। Île-de-France में प्रचलित दैनिक परामर्श दर पर, इस आकार पर दो दिन का हस्तक्षेप एक साल की बचत मिटा देता है।

इसलिए निष्कर्ष आर्थिक से कहीं ज़्यादा संगठनात्मक है:

• टीम में सिर्फ़ एक व्यक्ति PostgreSQL जानता है → बिना बहस, मैनेज्ड डेटाबेस;
• कई डेटाबेस, कई परिवेश, ग़ैर-मानक एक्सटेंशन की ज़रूरत → CloudNativePG, जो तीन-चार डेटाबेस से ही फ़ायदेमंद हो जाता है क्योंकि ऑपरेटर साझा हो जाता है;
• मौसमी लोड का उछाल → मैनेज्ड कंसोल से कुछ ही मिनटों में रीसाइज़ हो जाता है, जबकि सेल्फ-होस्टेड में क्लस्टर में नोड जोड़ना पड़ता है।

सबसे अधिक दिखने वाली गलतियाँ

डेटाबेस और बैकअप के लिए एक ही प्रदाता। OVHcloud डेटाबेस के WAL को उसी क्षेत्र की OVHcloud बकेट में भेजना यानी यह मान लेना कि क्षेत्र-स्तरीय कोई घटना दोनों को ले जाएगी। कम-से-कम दूसरा क्षेत्र चुनें, आदर्श रूप से दूसरा प्रदाता, और जहाँ उपलब्ध हो वहाँ ऑब्जेक्ट इम्यूटेबिलिटी चालू करें।

कभी रिस्टोर न किए गए बैकअप। पहले भी कहा जा चुका है, और डेटा के वास्तविक नुकसान का यह पहला कारण बना हुआ है।

कनेक्शन पूल का न होना। PostgreSQL हर कनेक्शन के लिए एक प्रोसेस आवंटित करता है। एक Node.js एप्लिकेशन जो प्रति पॉड 20 कनेक्शन का पूल खोलती है, 10 पॉड्स से गुणा होकर डिफ़ॉल्ट max_connections को भर देती है। CloudNativePG PgBouncer पर आधारित Pooler देता है; मैनेज्ड पक्ष पर जाँचें कि पूलर दिया गया है या नहीं, वरना क्लस्टर में एक तैनात करें।

असंगत मेमोरी सीमा। अगर shared_buffers और कुल work_mem मिलकर पॉड की मेमोरी सीमा पार कर जाएँ, तो कर्नेल प्रोसेस को मार देता है (OOMKill) और आप एक अवांछित फेलओवर देखते हैं। PostgreSQL पैरामीटर्स और कंटेनर सीमा के बीच कम-से-कम 25 % का अंतर रखें।

ग़लत चुना गया नेटवर्क स्टोरेज। किसी SME के अधिकांश लोड के लिए एक मानक ब्लॉक वॉल्यूम पर्याप्त है, लेकिन कम IOPS वाले वॉल्यूम पर ट्रांज़ैक्शनल डेटाबेस का नतीजा अनियमित प्रतिक्रिया समय होता है। क्वेरी को दोष देने से पहले अपने storageClass की स्टोरेज श्रेणी देखें।

अगर आप इस विषय पर क्लस्टर के बाकी हिस्सों के साथ ही काम कर रहे हैं, तो दो पड़ोसी मोर्चे हैं HTTP प्रवेश-बिंदु — देखें ingress-nginx से Gateway API पर माइग्रेशन पर हमारा लेख — और इमेज रजिस्ट्री पर प्रमाणीकरण, जिसका विवरण Kubernetes पर निजी GitLab इमेज में है। हमारी टीम इन निर्णयों में इंफ्रास्ट्रक्चर और संचालन सेवाओं के दायरे में सहयोग करती है, और जब डेटा स्कीमा भी दोबारा देखना हो तो एप्लिकेशन विकास के साथ मिलकर।

अक्सर पूछे जाने वाले प्रश्न

क्या कंटेनर में PostgreSQL प्रोडक्शन के लिए गंभीर विकल्प है?

हाँ, बशर्ते आप ऑपरेटर इस्तेमाल करें। कंटेनर समस्या नहीं है: परसिस्टेंट स्टोरेज और फेलओवर का ऑर्केस्ट्रेशन समस्या हैं। CloudNativePG दोनों को परसिस्टेंट वॉल्यूम और Kubernetes API के सहारे हल करता है। कई टेराबाइट के डेटाबेस इसी तरह प्रोडक्शन में चल रहे हैं। वहीं, हाथ से लिखा StatefulSet गंभीर विकल्प नहीं है।

RPO और RTO में ठोस अंतर क्या है?

RPO वह डेटा-मात्रा है जिसे खोना आप स्वीकार करते हैं: सतत WAL आर्काइविंग के साथ यह सेकंडों में होता है; रात के pg_dump के साथ घंटों में। RTO सेवा बहाल होने में लगने वाला समय है: रेप्लिका का प्रमोशन दसियों सेकंड लेता है, जबकि ऑब्जेक्ट स्टोरेज से 500 GB के डेटाबेस का पुनर्निर्माण दसियों मिनट। आर्किटेक्चर चुनने से पहले दोनों आँकड़े लिखित रूप में तय करें।

क्या मैनेज्ड डेटाबेस से CloudNativePG पर बिना डाउनटाइम माइग्रेट किया जा सकता है?

लगभग। CloudNativePG लॉजिकल रेप्लिकेशन (bootstrap.initdb.import या किसी पब्लिकेशन की सब्सक्रिप्शन) से बाहरी डेटाबेस से क्लस्टर बूटस्ट्रैप कर सकता है। लगातार रेप्लिकेट करें, सत्यापित करें, फिर कुछ मिनटों की विंडो में एप्लिकेशन स्विच करें। बाधा: लॉजिकल रेप्लिकेशन सीक्वेंस नहीं ले जाता — उन्हें फिर से सिंक करना याद रखें — और दोनों ओर PostgreSQL 10 या उससे ऊपर ज़रूरी है।

तीन इंस्टेंस चाहिए या दो काफ़ी हैं?

तीन। दो इंस्टेंस के साथ, रेप्लिका खोने पर पुनर्निर्माण के दौरान आप बिना रिडंडेंसी रह जाते हैं, और नोड मेंटेनेंस एक ठहराव-बिंदु बन जाता है। तीन इंस्टेंस से आप किसी नोड को खाली (kubectl drain) कर सकते हैं और कभी भी एक उपलब्ध सिंक्रोनस रेप्लिका से नीचे नहीं जाते।

और Neon जैसी सर्वरलेस पेशकशें?

वे अल्पकालिक प्री-प्रोडक्शन परिवेशों के लिए उपयुक्त हैं — Git ब्रांच के हिसाब से डेटाबेस ब्रांचिंग असली फ़ायदा है — और बहुत अनियमित लोड के लिए भी। नियमित ट्रैफ़िक वाले प्रोडक्शन एप्लिकेशन के लिए, उपयोग-आधारित बिलिंग शायद ही फ़ायदेमंद रहती है, और स्लीप मोड से जागने की लेटेंसी किसी सार्वजनिक पेज पर स्वीकार्य नहीं है।

सारांश

• हाथ से लिखा PostgreSQL StatefulSet कभी नहीं: या तो ऑपरेटर, या मैनेज्ड।
• CloudNativePG घोषणात्मक रेप्लिकेशन, फेलओवर, WAL आर्काइविंग और PITR देता है, Apache 2.0 लाइसेंस के तहत, केवल नोड्स और स्टोरेज की लागत पर — SME आकार पर अक्सर 25 से 60 €/माह।
• मैनेज्ड डेटाबेस (OVHcloud, Scaleway, RDS) उसी आकार पर 60 से 150 €/माह पड़ता है, पर ऑन-कॉल बोझ हटा देता है; प्रतिबद्ध होने से पहले एक्सटेंशन की श्वेतसूची जाँच लें।
• निर्णायक मानदंड मानवीय है: दो दिन का हस्तक्षेप एक साल की बचत मिटा देता है।
• WAL को डेटा वॉल्यूम से अलग करें और बैकअप किसी दूसरे प्रदाता के पास, या कम-से-कम दूसरे क्षेत्र में भेजें।
• हर तिमाही रिस्टोर जाँचें और अपना RPO तथा RTO काले-सफ़ेद में लिख लें।
• कनेक्शन पूल अनिवार्य है (PgBouncer, या CloudNativePG का Pooler ऑब्जेक्ट) जैसे ही कई एप्लिकेशन पॉड्स जुड़ने लगें।

आकार के चुनाव या बिना डाउनटाइम माइग्रेशन की व्यवहार्यता पर संदेह है? अपने डेटाबेस के आकार और उपलब्धता संबंधी बाधाओं के साथ हमें लिखें।