Postgres 16 बनाम 17 बनाम 18: लाभ मायने रखता है

तीनों संस्करण एक समग्र प्रदर्शन आंकड़े से भिन्न नहीं हैं। प्रत्येक आर्किटेक्चर के एक विशिष्ट बिंदु को हर बार एक अलग दर्शक वर्ग के साथ सही करता है: पोस्टग्रेज 17 के लिए बड़ी तालिकाएं, पोस्टग्रेज 18 के लिए उच्च विलंबता भंडारण। नीचे दी गई तालिका प्रत्येक परियोजना के विवरण में जाने से पहले, सभी दिनांकित, सत्यापन योग्य तथ्यों का सारांश देती है।

स्रोत: PostgreSQL प्रोजेक्ट (postgresql.org) के आधिकारिक रिलीज नोट्स, प्रत्येक प्रमुख रिलीज के बाद माइक्रोसॉफ्ट टेक कम्युनिटी और क्रंची डेटा द्वारा प्रकाशित विश्लेषणों के साथ क्रॉस-रेफर्ड। 24 अगस्त, 2026 को एक्सेस किया गया।

पोस्टग्रेज 17 से पहले, VACUUM ने साफ करने के लिए मृत टुपल्स की सूची को एक साधारण सरणी में संग्रहीत किया था, जिसका आकार maintenance_work_memथा। समस्या गणना की गति नहीं थी, बल्कि स्वयं संरचना थी: यह तालिका 1 जीबी के आसपास स्थिर थी, इससे कोई फर्क नहीं पड़ता कि इससे परे कितना कॉन्फ़िगर किया गया था। लगभग 178 मिलियन से अधिक मृत पंक्तियों वाली एक मेज पर, VACUUM को कई पासों में लूप करना पड़ा, प्रत्येक ने संपूर्ण अनुक्रमणिका को फिर से पढ़ा।

पोस्टग्रेज़ 17 इस सरणी को टिडस्टोर नामक संरचना से प्रतिस्थापित करता है, एक अनुकूली रेडिक्स ट्री जो टपल पहचानकर्ताओं को संग्रहीत करने के लिए आवश्यक स्थान को भारी रूप से संपीड़ित करता है। प्रोजेक्ट के आधिकारिक रिलीज़ नोट्स से संकेत मिलता है कि पुरानी संरचना से जुड़ी कृत्रिम छत के बिना, कुछ मामलों में VACUUM द्वारा उपयोग की जाने वाली मेमोरी में 20 गुना तक की कमी आई है। स्रोत: PostgreSQL 17 आधिकारिक रिलीज़ नोट्स, postgresql.org, 26 सितंबर, 2024। माइक्रोसॉफ्ट टेक कम्युनिटी और क्रंची डेटा प्रत्येक ने रिलीज़ के तुरंत बाद इस परिवर्तन का तकनीकी विश्लेषण प्रकाशित किया। दोनों उच्च विलोपन या अद्यतन दर के साथ कई सौ मिलियन पंक्तियों की तालिकाओं के लिए ठोस रुचि की पुष्टि करते हैं।

यह प्रोजेक्ट मुख्य रूप से एक विशिष्ट परिदृश्य को लाभान्वित करता है: उच्च विलोपन या अद्यतन दर वाली एक बड़ी तालिका। उपलब्ध मेमोरी की कमी के कारण VACUUM पहले कई पासों में चलता था। एक छोटी मेज पर, या मुख्य रूप से पढ़ने के भार पर, लाभ मामूली या अदृश्य भी रहता है।

दूसरा पोस्टग्रेज 17 प्रोजेक्ट एक अधिक विवेकशील बिंदु को छूता है: लेनदेन स्नैपशॉट की गणना। पोस्टग्रेज़ के एमवीसीसी दृश्यता नियमों को लागू करने के लिए प्रत्येक क्वेरी को यह जानना आवश्यक है कि अन्य लेनदेन क्या प्रगति पर हैं। अधिक संख्या में कोर और सक्रिय कनेक्शन वाली मशीन पर, इस गणना ने साझा आंतरिक संरचना पर विवाद उत्पन्न किया। यह एक अड़चन है जिसे परियोजना योगदानकर्ताओं द्वारा लंबे समय से प्रलेखित किया गया है।

पोस्टग्रेस 17 इस विवाद को कम करता है। प्रभाव को मुख्य रूप से मल्टी-कोर हार्डवेयर पर एक साथ कई सक्रिय कनेक्शनों के साथ उच्च समवर्ती उदाहरणों पर मापा जाता है। कम समवर्ती लोड पर, पोस्टग्रेज 16 के साथ अंतर मामूली रहता है: यह एक स्केलेबिलिटी परियोजना है, न कि प्रति पृथक अनुरोध में विलंबता में कमी।

यह लाभ कनेक्शन पूलर को प्रतिस्थापित नहीं करता है, यह बस इसकी आंतरिक लागत को कम करता है। यदि सक्रिय कनेक्शनों की संख्या पहले से ही आपकी बाधा है, तो प्रमुख संस्करण पीछे रह जाता है। हमारी max_connections ट्यूनिंग गाइड और हमारी PgBouncer लेनदेन मोड तुलना इस विषय को अधिक विस्तार से देखें।

पोस्टग्रेज़ 18, सितंबर 2025 के अंत में जारी किया गया, एक अधिक संरचनात्मक समस्या का समाधान करता है। तब तक, प्रत्येक पोस्टग्रेज डिस्क रीड ने उस प्रक्रिया को अवरुद्ध कर दिया था जिसने इसका अनुरोध किया था। नया एसिंक्रोनस इनपुट-आउटपुट (एआईओ) सबसिस्टम एक प्रक्रिया को क्रमिक रूप से प्रत्येक की प्रतीक्षा करने के बजाय, समानांतर में कई रीडिंग शुरू करने और उनके पूरा होने तक काम करना जारी रखने की अनुमति देता है।

io_method पैरामीटर इस व्यवहार को नियंत्रित करता है: worker (I/O को समर्पित प्रक्रियाएं, डिफ़ॉल्ट) या लिनक्स पर io_uring, जब पोस्टग्रेज को इस समर्थन के साथ संकलित किया गया था। अनुक्रमिक स्कैन, बिटमैप हीप स्कैन और VACUUM पहले लाभार्थी हैं, विशेष रूप से उच्च विलंबता भंडारण पर: स्थानीय NVMe के बजाय नेटवर्क डिस्क, क्लाउड वॉल्यूम।

प्लैनेटस्केल, जो एक प्रबंधित पोस्टग्रेज पेशकश प्रदान करता है, ने इस I/O परिवर्तन पर केंद्रित अपनी पोस्टग्रेज 17 बनाम 18 तुलनाएँ प्रकाशित की हैं। ये उनके अपने बुनियादी ढांचे पर माप हैं, न कि वे आंकड़े जिन्हें हमने यहां स्वतंत्र रूप से पुन: प्रस्तुत किया है। इसे एक संकेत के रूप में लें कि विषय आपके वास्तविक भार पर परीक्षण के लायक है, न कि सार्वभौमिक प्रतिशत के रूप में।

पोस्टग्रेज 18 का सामान्यीकृत एआईओ पोस्टग्रेज 17 में शुरू की गई परियोजना को जारी रखता है, कोई पृथक परिवर्तन नहीं। संस्करण 17 ने पहले ही स्ट्रीमिंग I/O इंटरफ़ेस पेश कर दिया था, लेकिन विश्लेषण और अनुक्रमिक स्कैन तक सीमित था। पोस्टग्रेज़ 18 इसी तर्क को VACUUM और बिटमैप हीप स्कैन सहित संचालन के व्यापक दायरे तक विस्तारित करता है। इसलिए दोनों संस्करणों को प्रगति के रूप में पढ़ा जाता है, न कि I/O पर दो अलग-अलग दांवों के रूप में।

तीन अन्य पोस्टग्रेज़ 18 परिवर्तन निगरानी के लायक हैं, भले ही वे सीधे तौर पर कच्चे प्रदर्शन को संबोधित न करें।

मल्टी-कॉलम बी-ट्री इंडेक्स पर स्किप स्कैन पोस्टग्रेज को एक समग्र इंडेक्स का उपयोग करने की अनुमति देता है, भले ही क्वेरी उसके हेड कॉलम पर फ़िल्टर न हो। पोस्टग्रेज़ 18 से पहले, इस परिदृश्य में अक्सर तालिका के पूर्ण स्कैन, या एक अतिरिक्त समर्पित सूचकांक के निर्माण की आवश्यकता होती थी।

STORED निर्दिष्ट नहीं होने पर उत्पन्न वर्चुअल कॉलम (GENERATED ALWAYS AS (...) VIRTUAL) डिफ़ॉल्ट व्यवहार बन जाते हैं। वर्चुअल कॉलम की गणना डिस्क पर लिखे जाने के बजाय पढ़ने पर की जाती है, जिससे हर बार स्रोत पंक्ति डालने या अद्यतन करने पर लिखी जाने वाली मात्रा कम हो जाती है।

पोस्टग्रेज़ 18 अंततः एससीआरएएम, प्रमाणपत्र या एलडीएपी जैसे मौजूदा तंत्रों के साथ-साथ प्रमाणीकरण पक्ष (आरएफसी 8628, डिवाइस प्रवाह) पर ओएथ 2.0 के लिए समर्थन जोड़ता है। किसी भी संगठन के लिए एक प्रासंगिक बिंदु जो पहले से ही बाहरी OAuth/OIDC प्रदाता के माध्यम से अपनी पहचान को केंद्रीकृत करता है।

ऑराबेस में, टेनेंट डेटाबेस वर्तमान में पोस्टग्रेस 16.15 में चलता है, 17 में नहीं। इसे सीधे रिपॉजिटरी में सत्यापित किया जा सकता है: संदर्भ सीएनपीजी छवि (docker/Postgres.CNPG.Dockerfile) ghcr.io/cloudnative-pg/postgresql:16-standard-bookwormसे शुरू होती है, जिसे डाइजेस्ट द्वारा पिन किया जाता है, जो साझा स्तर (docker/Postgres.Dockerfile) के समान प्रमुख संस्करण है। 24 अगस्त 2026 को सत्यापित।

कोड यह भी दस्तावेज करता है कि क्यों। k8s_tenant.rs में एक सुधार टिप्पणी बताती है कि पहले वाला फ़ॉलबैक गलती से postgresql:17.2की ओर इशारा कर गया था। उस समय दिया गया कारण, मानक छवि में पीजीवेक्टर शामिल नहीं होगा, सत्यापन के बाद गलत निकला। दोनों छवियों में पीजीवेक्टर है: 17.2 पर 0.8.0, 16-मानक-किताबी कीड़ा पर 0.8.5, जिसे फ्लीट क्लस्टर पर मापा गया है।

वास्तविक जोखिम, जिसे टिप्पणी में ही प्रलेखित किया गया है, कहीं और है: क्लस्टर बन जाने के बाद CloudNativePG किसी भी बड़े संस्करण को डाउनग्रेड करने से रोकता है। पोस्टग्रेज 17 में गलती से प्रावधानित एक बेड़ा अपरिवर्तनीय होगा, जबकि ऑराबेस में शुरू से अंत तक मान्य की गई हर चीज पोस्टग्रेज 16 में थी।

// यदि TENANT_POSTGRES_IMAGE परिभाषित नहीं है तो प्रमुख संस्करण बरकरार रखा जाता है
let repli = "ghcr.io/cloudnative-pg/postgresql:16-standard-bookworm";

tracing::warn!(
    image = repli,
    "TENANT_POSTGRES_IMAGE non défini : repli sur la version validée."
);

यह पोस्टग्रेस 17 पर कोई निर्णय नहीं है। यह परिचालन संबंधी विवेक की नीति है: किसी उत्पादन बेड़े को तब तक बड़े संस्करण में न बदलें जब तक कि अंत-से-अंत सत्यापन न हो जाए। यही तर्क किसी भी टीम पर लागू होता है जो क्लाउडनेटिवपीजी या समकक्ष कुबेरनेट्स ऑपरेटर के माध्यम से पोस्टग्रेज का प्रबंधन करती है। सवाल केवल अपेक्षित प्रदर्शन लाभ का ही नहीं है, बल्कि कुछ गलत होने पर वापसी का रास्ता भी है।

क्या अब आपको पोस्टग्रेज़ 17 या 18 पर माइग्रेट करना चाहिए?

तीन मानदंड सार्वभौमिक आंकड़े की प्रतीक्षा किए बिना निर्णय लेना संभव बनाते हैं। सबसे पहले, आपकी सबसे बड़ी तालिकाओं का आकार और उत्परिवर्तन दर: यदि VACUUM पहले से ही कई पासों में चल रहा है, तो पोस्टग्रेज 17 मेमोरी वर्कसाइट सीधे आपके मामले पर लागू होती है। फिर, आपका भंडारण: कम विलंबता वाले स्थानीय एसएसडी पर, पोस्टग्रेज 18 का एसिंक्रोनस I/O नेटवर्क वॉल्यूम की तुलना में कम प्रदान करता है। अंत में, आपका रास्ता वापस: एक ऐसे ऑपरेटर पर जो प्रमुख डाउनग्रेड को प्रतिबंधित करता है, डिस्पोजेबल वातावरण पर पहले परीक्षण करना एक वैकल्पिक सावधानी नहीं है।

सीधे तौर पर, यही नियम कुबेरनेट्स ऑपरेटर द्वारा प्रबंधित किसी भी बेड़े पर लागू होता है। पहले लक्ष्य रिलीज में एक परीक्षण क्लस्टर का प्रावधान करें, फिर उस पर अपने उत्पादन के लोड प्रतिनिधि को दोबारा चलाएं। वास्तविक क्लस्टर को केवल तभी स्पर्श करें जब यह परीक्षण शुरू से अंत तक मान्य हो जाए, न कि केवल रिलीज़ नोट्स को पढ़ें। यदि आपका निर्णय इस प्रकार के परिवर्तन को अवशोषित करने के लिए समर्पित आधार और साझा आधार के बीच चयन से संबंधित है, तो हमारा लेख समर्पित बनाम साझा आधार इस कोण की पड़ताल करता है।

पोस्टग्रेज़ 16, 17 और 18 के बीच चयन केवल इस बारे में नहीं है कि कौन सा संस्करण "सबसे तेज़" है। पोस्टग्रेस 17 बड़ी तालिकाओं पर एक वास्तविक संरचनात्मक वैक्यूम समस्या को ठीक करता है और उच्च संगामिति पर विवाद को कम करता है। पोस्टग्रेस 18 एसिंक्रोनस I/O के साथ आगे बढ़ता है, एक वास्तुशिल्प परिवर्तन जिसे सामान्यीकृत होने से पहले आपके वास्तविक लोड और भंडारण पर परीक्षण की आवश्यकता होती है।

सबसे अधिक बार भुलाया जाने वाला मानदंड प्रदर्शन नहीं है, यह प्रतिवर्तीता है। CloudNativePG जैसे ऑपरेटर पर, इस तथ्य के बाद एक प्रमुख संस्करण अपग्रेड पूर्ववत नहीं किया जाता है। उत्पादन बेड़े पर स्विच करने से पहले, असली सवाल न केवल अपेक्षित लाभ का है, बल्कि परीक्षण विफल होने पर वापसी का रास्ता भी है। यदि आप इस संस्करण के उन्नयन के लिए तैयारी कर रहे हैं, तो हमारी उत्पादन में ट्यूनिंग चेकलिस्ट को पोस्टग्रेज करती है एक प्रमुख संस्करण परिवर्तन के बाद पुन: मान्य करने के लिए सेटिंग्स का विवरण देती है।