PostgreSQL 19 रिलीज़ के करीब है: डेटाबेस टीमों को अभी क्या टेस्ट करना चाहिए

PostgreSQL 19 नेटिव टेबल रीपैकिंग, क्वेरी प्लान पर ज़्यादा नियंत्रण और रेप्लिकेशन तथा मेंटेनेंस में सुधार लाता है। 19 नवंबर 2026 को जनरल अवेलेबिलिटी की योजना के साथ, टीमों को इन लाभों का मूल्यांकन संगतता और ऑपरेशन से जुड़ी महत्वपूर्ण सीमाओं के साथ करना चाहिए।

PostgreSQL का कोई मेजर अपग्रेड यह बदल सकता है कि कोई एप्लिकेशन अपने डेटा को कैसे क्वेरी, मेंटेन और रेप्लिकेट करता है। ये बदलाव प्रदर्शन सुधार सकते हैं और ऑपरेशनल काम घटा सकते हैं। ये ऐसी निर्भरताएं भी उजागर कर सकते हैं जो पिछले वर्ज़न में स्पष्ट नहीं थीं। PostgreSQL 19 इस आकलन को अभी प्रासंगिक बनाता है।

PostgreSQL Global Development Group ने 15 अक्टूबर 2026 को PostgreSQL 19 RC1 जारी किया। RC2 के लिए 12 नवंबर निर्धारित है, और जनरल अवेलेबिलिटी 19 नवंबर के लिए नियोजित है, बशर्ते रिलीज़ रोकने वाली कोई समस्या सामने न आए। रिलीज़ कैंडिडेट (release candidate) काफ़ी हद तक नियोजित अंतिम रिलीज़ जैसा ही होता है, हालांकि जनरल अवेलेबिलिटी से पहले कुछ सुधार अभी भी लागू किए जा सकते हैं।

6 नवंबर तक PostgreSQL 19 अभी भी एक रिलीज़ कैंडिडेट है। यह एक प्री-रिलीज़ वर्ज़न है, और टीमों को इसे प्रोडक्शन के बाहर टेस्ट करना चाहिए। डेटाबेस टीमों के लिए उपयोगी प्रश्न यह है कि अंतिम रिलीज़ से पहले कौन से बदलाव टेस्ट किए जाने योग्य हैं।

क्या बदल रहा है?

PostgreSQL 19 टेबल मेंटेनेंस, क्वेरी प्लानिंग, रेप्लिकेशन और डेटाबेस ऑपरेशन में सुधार लाता है।

क्षमता	क्या बदलता है	टीमों को किसका मूल्यांकन करना चाहिए
नेटिव REPACK	डिस्क स्पेस वापस पाने के लिए टेबल को दोबारा लिखता है	लॉकिंग, स्टोरेज की ज़रूरतें और ट्रांज़ैक्शन विज़िबिलिटी
pg_plan_advice	प्लानर के चुनिंदा निर्णयों को प्रभावित करता है	क्वेरी प्रदर्शन और पुरानी पड़ चुकी एडवाइस का जोखिम
बेहतर वैक्यूम ऑपरेशन	पैरेलल इंडेक्स मेंटेनेंस और प्राथमिकता निर्धारण में सुधार	मेंटेनेंस में संसाधनों का उपयोग
लॉजिकल रेप्लिकेशन	सीक्वेंस सिंक्रोनाइज़ेशन और ज़्यादा लचीला एक्टिवेशन	माइग्रेशन और स्विचओवर का व्यवहार
स्टैंडबाय WAIT कमांड	किसी निर्दिष्ट राइट-अहेड लॉग (WAL) पोज़िशन की प्रतीक्षा करता है	रीड कंसिस्टेंसी, लेटेंसी और टाइमआउट हैंडलिंग
संगतता संबंधी बदलाव	बदले गए डिफ़ॉल्ट और हटाई गई कार्यक्षमता	एप्लिकेशन, ऑथेंटिकेशन और एक्सटेंशन पर निर्भरताएं

ये क्षमताएं अलग-अलग ज़रूरतें पूरी करती हैं। टीमों को हर फ़ीचर को बराबर टेस्ट करने के बजाय उन क्षमताओं को प्राथमिकता देनी चाहिए जो किसी वास्तविक ऑपरेशनल समस्या को हल करती हैं।

स्रोत: PostgreSQL 19 preliminary release notes।

1. नेटिव REPACK मेंटेनेंस का एक नया विकल्प देता है

PostgreSQL टेबल में पंक्तियां (rows) अपडेट या डिलीट होने पर अप्रयुक्त स्पेस जमा हो सकता है। सामान्य VACUUM इस स्पेस के बड़े हिस्से को दोबारा उपयोग योग्य बनाता है, लेकिन आमतौर पर इसे ऑपरेटिंग सिस्टम को वापस नहीं लौटाता। PostgreSQL 19 नेटिव REPACK कमांड लाता है, जो स्पेस वापस पाने के लिए किसी टेबल और उसके इंडेक्स को दोबारा लिखता है। यह किसी इंडेक्स के अनुसार पंक्तियों को फिर से व्यवस्थित भी कर सकता है।

CONCURRENTLY विकल्प ऑपरेशन के ज़्यादातर हिस्से के दौरान सामान्य टेबल गतिविधि की अनुमति देता है, जिससे पारंपरिक टेबल रीराइट के लिए ज़रूरी लंबे एक्सक्लूसिव लॉक से बचा जा सकता है। यह उपयोगी है, लेकिन कॉन्करेंट रीपैकिंग की महत्वपूर्ण सीमाएं हैं।

यह MVCC-सुरक्षित नहीं है। MVCC (multiversion concurrency control) वह तंत्र है जो हर ट्रांज़ैक्शन को डेटा के एक सुसंगत स्नैपशॉट (snapshot) से काम करने देता है। PostgreSQL चेतावनी देता है कि जो ट्रांज़ैक्शन रीपैकिंग ऑपरेशन शुरू होने से पहले लिए गए स्नैपशॉट का उपयोग करते हैं, उन्हें रीपैकिंग ट्रांज़ैक्शन के कमिट होने के बाद टेबल खाली दिख सकती है।

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

अन्य प्रतिबंध भी लागू होते हैं। उदाहरण के लिए, कॉन्करेंट रीपैकिंग पार्टिशन्ड टेबल (partitioned tables), अनलॉग्ड टेबल (unlogged tables) और उपयुक्त पहचान जानकारी (identity) के बिना कुछ टेबल के लिए उपलब्ध नहीं है। अगर रीपैकिंग के दौरान टेबल पर DDL कमांड चलें, जो टेबल की संरचना बदलते हैं, या अन्य दस्तावेज़ित स्थितियों में, तो रीपैक विफल भी हो सकता है।

इन कारणों से इसे नियमित VACUUM का सीधा विकल्प (drop-in replacement) नहीं माना जाना चाहिए। डेटाबेस टीमों को पहले प्रतिनिधि टेबल, उपलब्ध डिस्क क्षमता, ट्रांज़ैक्शन व्यवहार, लॉकिंग और रिकवरी प्रक्रियाओं को टेस्ट करना चाहिए। जहां चिंता ट्रांज़ैक्शन ID रैपअराउंड (wraparound) को रोकने की हो, वहां PostgreSQL अब भी REPACK की नहीं, बल्कि VACUUM की सिफ़ारिश करता है।

स्रोत: PostgreSQL 19, REPACK command documentation।

2. क्वेरी प्लानिंग पर नियंत्रण बढ़ता है

PostgreSQL सामान्यतः आंकड़ों (statistics), लागत के अनुमानों और ऑप्टिमाइज़र नियमों का उपयोग करके एक्ज़ीक्यूशन प्लान चुनता है। कभी-कभी उसके अनुमान ऐसे प्लान की ओर ले जाते हैं जो किसी विशेष वर्कलोड के लिए खराब प्रदर्शन करता है। PostgreSQL 19 pg_plan_advice मॉड्यूल लाता है, जो टीमों को प्लानर (planner) के चुनिंदा निर्णयों का वर्णन करने और उन्हें प्रभावित करने देता है। संबंधित pg_stash_advice एक्सटेंशन संग्रहीत एडवाइस को अलग-अलग क्वेरी से जोड़ सकता है।

ये टूल टीमों को प्लान रिग्रेशन की जांच करने या किसी ज्ञात उपयोगी प्लान को स्थिर करने में मदद कर सकते हैं। हालांकि, प्लान एडवाइस क्वेरी ऑप्टिमाइज़र की जगह नहीं लेती। यह प्लानर के उपलब्ध विकल्पों को सीमित करके काम करती है। यह PostgreSQL को ऐसे प्लान का उपयोग करने के लिए बाध्य नहीं कर सकती जिसे प्लानर अमान्य मानता है या जनरेट ही नहीं करता।

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

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

स्रोत: PostgreSQL 19, pg_plan_advice documentation और PostgreSQL 19 preliminary release notes।

3. रेप्लिकेशन ज़्यादा लचीला होता है

PostgreSQL 19 ऐसे बदलाव लाता है जो चुनिंदा रेप्लिकेशन और माइग्रेशन वर्कफ़्लो को सरल बना सकते हैं। एक सुधार लॉजिकल रेप्लिकेशन सब्सक्राइबर (subscriber) को सीक्वेंस वैल्यू पब्लिशर (publisher) के अनुरूप बनाए रखने देता है। यह उन माइग्रेशन के दौरान उपयोगी हो सकता है जिनमें स्विचओवर के बाद जनरेट किए गए आइडेंटिफ़ायर सही ढंग से आगे बढ़ते रहने चाहिए।

PostgreSQL 19 यह भी अनुमति देता है कि समर्थित स्थितियों में wal_level के replica पर सेट होने पर लॉजिकल रेप्लिकेशन सक्षम किया जा सके, और इसके लिए वह रीस्टार्ट ज़रूरी नहीं होता जो पहले इस कॉन्फ़िगरेशन को बदलने से जुड़ा था। ये बदलाव कॉन्फ़िगरेशन और माइग्रेशन का कुछ काम घटाते हैं, लेकिन सिंक्रोनाइज़ेशन, डेटा की सुसंगतता या फ़ेलओवर व्यवहार को सत्यापित करने की ज़रूरत को खत्म नहीं करते। एक और महत्वपूर्ण सुधार स्टैंडबाय सर्वर पर रीड कंसिस्टेंसी से संबंधित है।

WAIT कमांड और रीड-योर-राइट्स कंसिस्टेंसी

एसिंक्रोनस रेप्लिकेशन में कोई राइट स्टैंडबाय (standby) द्वारा रीप्ले किए जाने से पहले ही प्राइमरी (primary) पर कमिट हो सकता है। इसलिए स्टैंडबाय से तुरंत पढ़ने वाले एप्लिकेशन को पुराना डेटा दिख सकता है। PostgreSQL 19 WAIT FOR LSN लाता है, जिससे कोई एप्लिकेशन तब तक प्रतीक्षा कर सकता है जब तक कोई निर्दिष्ट राइट-अहेड लॉग पोज़िशन न आ जाए। लॉग सीक्वेंस नंबर (LSN) राइट-अहेड लॉग में किसी पोज़िशन की पहचान करता है।

रीड-योर-राइट्स (read-your-writes) व्यवहार के लिए, एप्लिकेशन को संबंधित ट्रांज़ैक्शन के कमिट होने के बाद प्राइमरी से एक उपयुक्त WAL लोकेशन प्राप्त करनी होगी, और फिर स्टैंडबाय पर उस लोकेशन के रीप्ले होने की प्रतीक्षा करनी होगी। WAL के लिखे जाने, फ़्लश होने और रीप्ले होने के बीच का अंतर मायने रखता है। केवल सफल रीप्ले से ही यह स्थापित होता है कि संबंधित कमिट किए गए बदलाव उस स्टैंडबाय पर बाद की रीड के लिए उपलब्ध हैं।

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

स्रोत: PostgreSQL 19, WAIT documentation।

4. मेंटेनेंस और प्रदर्शन में सुधार

PostgreSQL 19 यह भी सुधारता है कि डेटाबेस बैकग्राउंड का काम कैसे करते हैं। बदलावों में ज़्यादा लचीला ऑटोवैक्यूम (autovacuum) प्राथमिकता निर्धारण और पैरेलल इंडेक्स मेंटेनेंस शामिल हैं, साथ ही प्लानिंग, एक्ज़ीक्यूशन और I/O में सुधार भी।

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

इसी तरह, ज़्यादा परिष्कृत ऑटोवैक्यूम प्राथमिकता निर्धारण से टेबल की वृद्धि और मेंटेनेंस की प्रगति की निगरानी की ज़रूरत खत्म नहीं होती। टीमों को अपग्रेड से पहले और बाद में मेंटेनेंस की अवधि, I/O उपयोग, क्वेरी लेटेंसी और संसाधनों के लिए होड़ (resource contention) को मापना चाहिए। रिलीज़ नोट्स क्षमताओं का वर्णन करते हैं, लेकिन प्रोडक्शन प्रदर्शन को प्रतिनिधि वर्कलोड पर साबित करना होगा।

स्रोत: PostgreSQL 19, Routine Vacuuming।

5. संगतता संबंधी बदलावों पर विशेष ध्यान देना ज़रूरी है

PostgreSQL 19 के कई बदलाव मौजूदा एप्लिकेशन और ऑपरेशनल टूलिंग को प्रभावित कर सकते हैं।

बदलाव	संभावित परिणाम
JIT (just-in-time) कंपाइलेशन डिफ़ॉल्ट रूप से बंद	कुछ एनालिटिकल वर्कलोड को स्पष्ट JIT कॉन्फ़िगरेशन की ज़रूरत पड़ सकती है
RADIUS ऑथेंटिकेशन हटाया गया	RADIUS का उपयोग करने वाले इंस्टॉलेशन को किसी अन्य समर्थित ऑथेंटिकेशन विधि पर माइग्रेट करना होगा
standard_conforming_strings अनिवार्य रूप से चालू	पिछले व्यवहार पर निर्भर पुरानी SQL स्क्रिप्ट या डेटाबेस डंप में बदलाव की ज़रूरत पड़ सकती है
inet और cidr के लिए डिफ़ॉल्ट इंडेक्स ऑपरेटर क्लास बदली गईं	pg_upgrade उन क्लस्टर को अस्वीकार करता है जिनमें इन टाइप पर btree_gist इंडेक्स हैं, इसलिए पहले उन्हें ठीक करने का काम ज़रूरी है
सिस्टम इंटरफ़ेस और कॉन्फ़िगरेशन में बदलाव	मॉनिटरिंग टूल, एक्सटेंशन या ऑटोमेशन को संगतता अपडेट की ज़रूरत पड़ सकती है

एक विशेष रूप से महत्वपूर्ण मुद्दा डेटाबेस डंप से जुड़ा है। PostgreSQL चेतावनी देता है कि standard_conforming_strings बंद रहते हुए पुराने pg_dump या pg_dumpall वर्ज़न से बनाए गए डंप शायद PostgreSQL 19 में सही ढंग से लोड न हों। टीमों को यह मान लेने के बजाय कि कोई पुराना बैकअप संगत है, एक समर्थित डंप प्रक्रिया का उपयोग करना चाहिए और रीस्टोर को सत्यापित करना चाहिए।

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

स्रोत: PostgreSQL 19, Migration and Compatibility Notes।

डेटाबेस टीमों को अभी क्या टेस्ट करना चाहिए?

रिलीज़ कैंडिडेट का एक उपयोगी मूल्यांकन केंद्रित रह सकता है।

एप्लिकेशन संगतता: PostgreSQL 19 RC1 पर प्रतिनिधि एप्लिकेशन और इंटीग्रेशन टेस्ट चलाएं। SQL व्यवहार, ऑथेंटिकेशन, एक्सटेंशन और डेटाबेस ड्राइवर को शामिल करें।

महत्वपूर्ण क्वेरी: व्यावसायिक संचालन को प्रभावित करने वाली क्वेरी के एक्ज़ीक्यूशन प्लान और वास्तविक प्रदर्शन की तुलना करें।

मेंटेनेंस व्यवहार: प्रतिनिधि डेटा पर REPACK और वैक्यूम सुधारों को टेस्ट करें। डिस्क उपयोग, लॉकिंग, पुराने स्नैपशॉट का व्यवहार और विफलता की स्थितियां शामिल करें।

रेप्लिकेशन: जहां ये फ़ीचर प्रासंगिक हों, वहां सीक्वेंस सिंक्रोनाइज़ेशन, स्टैंडबाय WAIT व्यवहार, लेटेंसी और एरर हैंडलिंग को सत्यापित करें।

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

ये टेस्ट प्रोडक्शन के बाहर होने चाहिए। RC1 घोषणा के अनुसार जनरल अवेलेबिलिटी से पहले और सुधार अभी भी लागू किए जा सकते हैं, इसलिए रिलीज़ कैंडिडेट प्रोडक्शन वर्कलोड का आधार नहीं है।

मौजूदा PostgreSQL इंस्टॉलेशन का क्या?

हर संगठन को तुरंत PostgreSQL 19 की ज़रूरत नहीं है। जो टीमें पहले से समर्थित PostgreSQL वर्ज़न चला रही हैं, उन्हें मौजूदा सुरक्षा अपडेट बनाए रखने चाहिए और साथ ही यह आकलन करना चाहिए कि मेजर अपग्रेड सार्थक ऑपरेशनल मूल्य देता है या नहीं।

PostgreSQL 14 पर ज़्यादा तत्काल ध्यान देने की ज़रूरत है। PostgreSQL प्रोजेक्ट ने वर्ज़न 14 के लिए कम्युनिटी सपोर्ट की समाप्ति 12 नवंबर 2026 को निर्धारित की है।

जो संगठन अभी भी PostgreSQL 14 का उपयोग कर रहे हैं, उन्हें किसी समर्थित वर्ज़न पर जाने को प्राथमिकता देनी चाहिए। इसका मतलब यह ज़रूरी नहीं कि PostgreSQL 19 की प्रतीक्षा की जाए या उसे पहली रिलीज़ के दिन ही अपनाया जाए।

स्रोत: PostgreSQL versioning policy।

PostgreSQL 19 का व्यावहारिक महत्व

PostgreSQL 19 डेटाबेस मेंटेनेंस, क्वेरी प्लानिंग पर नियंत्रण और रेप्लिकेशन में उपयोगी सुधार देता है। यह व्यवहार से जुड़े ऐसे बदलाव भी लाता है जिनके लिए सोच-समझकर टेस्ट करना ज़रूरी है। नेटिव रीपैकिंग स्पेस वापस दिला सकती है, लेकिन कॉन्करेंट ऑपरेशन की ट्रांज़ैक्शन विज़िबिलिटी और संसाधनों से जुड़ी महत्वपूर्ण सीमाएं हैं। प्लानर एडवाइस कठिन क्वेरी को संभाल सकती है, लेकिन वर्कलोड बदलने पर नुकसानदेह हो सकती है। रेप्लिकेशन सुधार ज़्यादा नियंत्रण देते हैं, लेकिन सुसंगतता और विफलता को सावधानी से संभालना फिर भी ज़रूरी है।

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

---

संदर्भ और आगे पढ़ें

1. PostgreSQL Global Development Group, PostgreSQL 19 RC1 Released। 15 अक्टूबर 2026।
2. PostgreSQL 19 Release Notes। फ़ीचर और संगतता के प्रारंभिक विवरण।
3. PostgreSQL 19 REPACK Documentation। ऑपरेशनल आवश्यकताएं और MVCC चेतावनी।
4. PostgreSQL 19 pg_plan_advice Documentation। प्लानर का व्यवहार और सीमाएं।
5. PostgreSQL 19 WAIT Documentation। स्टैंडबाय कंसिस्टेंसी और टाइमआउट व्यवहार।
6. PostgreSQL 19 Routine Vacuuming। वैक्यूम और पैरेलल मेंटेनेंस का व्यवहार।
7. PostgreSQL Versioning Policy। समर्थित वर्ज़न और सपोर्ट समाप्ति की तारीखें।

स्रोत सत्यापन: 6 नवंबर 2026। PostgreSQL 19 अभी भी एक रिलीज़ कैंडिडेट है, और यहां उद्धृत PostgreSQL 19 डॉक्यूमेंटेशन पेज प्री-रिलीज़ वर्ज़न हैं। RC2 की 12 नवंबर और जनरल अवेलेबिलिटी की 19 नवंबर की तारीखें नियोजित हैं, पुष्ट रिलीज़ नहीं। सार्वजनिक प्रकाशन से पहले फ़ीचर और संगतता विवरणों को अंतिम रिलीज़ डॉक्यूमेंटेशन के आधार पर फिर से जांचा जाना चाहिए।