PostgreSQL JSONB बनाम normalized टेबल्स: निर्णय और माइग्रेशन

असली समस्या: तेज़ी से बनाना बिना खुद को फँसाए

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

तेज़ इटरेशन सिर्फ़ स्क्रीन तेज़ी से भेजना नहीं है। इसका मतलब है कि आप फ़ील्ड जोड़, नाम बदल और हटाएँ बिना रिपोर्ट्स, इंटिग्रेशन या पुराने रिकॉर्ड तोड़े। इसका मतलब यह भी है कि आप नए सवालों का जवाब दे सकें ("पिछले महीने कितने ऑर्डर में डिलीवरी नोट्स मिस थे?") बिना हर क्वेरी को एक-ऑफ़ स्क्रिप्ट बनाए।

इसलिए शुरुआती दौर में JSONB और normalized टेबल्स के बीच चुनाव मायने रखता है। दोनों काम कर सकते हैं, और दोनों गलत उपयोग पर दर्द दे सकते हैं। JSONB आज़ादी जैसा लगता है क्योंकि आप आज लगभग कुछ भी स्टोर कर सकते हैं। Normalized टेबल्स ज़्यादा सुरक्षित लगती हैं क्योंकि वे संरचना थोपती हैं। असली लक्ष्य है स्टोरेज मॉडल को मेल करना इस बात से कि आपका डेटा अभी कितना अनिश्चित है, और कितनी तेज़ी से उसे भरोसेमंद बनना है।

जब टीमें गलत मॉडल चुनती हैं, तो लक्षण आमतौर पर स्पष्ट होते हैं:

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

व्यावहारिक निर्णय यह है: आप कहाँ फ्लेक्सिबिलिटी चाहते हैं (और कुछ समय के लिए असंगतता बर्दाश्त कर सकते हैं), और कहाँ स्ट्रक्चर चाहिए (क्योंकि डेटा पैसे, ऑपरेशंस, या कम्प्लायंस को ड्राइव करता है)?

JSONB और normalized टेबल्स — सरलता से समझाएँ

PostgreSQL डेटा क्लासिक कॉलम्स (text, number, date) में स्टोर कर सकता है। यह एक कॉलम में पूरा JSON डॉक्यूमेंट भी JSONB के रूप में स्टोर कर सकता है। फर्क "नया बनाम पुराना" नहीं है। यह इस बात का है कि आप डेटाबेस से क्या गारंटी चाहते हैं।

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

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

दैनिक काम में ट्रेडऑफ़ सीधे होते हैं:

• JSONB: डिफ़ॉल्ट रूप से लचीला, बदलना आसान, ड्रिफ्ट के लिए आसान।
• Normalized टेबल्स: बदलने में सोच-समझकर, वैलिडेट करना आसान, लगातार क्वेरी करना आसान।

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

जब तेज़ इटरेशन के लिए JSONB सही टूल है

JSONB अच्छा विकल्प है जब आपका सबसे बड़ा जोखिम डेटा का गलत आकार बनना है, न कि कड़े नियम लागू करना। अगर आपका प्रोडक्ट अभी अपना वर्कफ़्लो ढूँढ रहा है, तो सब कुछ फिक्स्ड टेबल्स में ज़ोर देना आपको लगातार माइग्रेशंस के साथ धीमा कर सकता है।

एक अच्छा संकेत है जब फ़ील्ड्स साप्ताहिक रूप से बदलते हैं। एक ऑनबोर्डिंग फ़ॉर्म सोचें जहाँ मार्केटिंग बार-बार प्रश्न जोड़ती है, लेबल बदलती है, और स्टेप्स हटाती है। JSONB आपको हर सबमिशन को जैसा है वैसा स्टोर करने देता है, भले ही कल का वर्शन अलग दिखे।

JSONB "अज्ञातों" के लिए भी फिट बैठता है: वे डेटा जिन्हें आप अभी पूरी तरह नहीं समझते, या डेटा जिसे आप कंट्रोल नहीं करते। अगर आप पार्टनर्स से webhook payloads इनजेस्ट करते हैं, तो JSONB में raw payload सेव करने से आप नए फ़ील्ड्स को तुरंत सपोर्ट कर सकते हैं और बाद में तय कर सकते हैं कि क्या फर्स्ट-क्लास कॉलम बनना चाहिए।

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

एक गार्डरेल जो अपेक्षा से ज़्यादा मदद करता है: उपयोग की जाने वाली कीज़ का एक छोटा, साझा नोट रखें ताकि अलग-अलग रो में एक ही फ़ील्ड के पाँच वर्तनी न बन जाएँ।

जब normalized टेबल्स दीर्घकालिक रूप से सुरक्षित विकल्प हैं

Normalized टेबल्स तब जीतते हैं जब डेटा "सिर्फ़ इस फीचर के लिए" नहीं रहता बल्कि साझा, क्वेरी और भरोसेमंद बन जाता है। अगर लोग रिकॉर्ड्स को कई तरीकों से स्लाइस और फ़िल्टर करेंगे (स्थिति, मालिक, क्षेत्र, समय अवधि), तो कॉलम और रिलेशन व्यवहार को अनुमानित और ऑप्टिमाइज़ करना आसान बनाते हैं।

नॉर्मलाइज़ेशन भी मायने रखता है जब नियम डेटाबेस द्वारा लागू होना चाहिए, न कि "बेहतर प्रयास" एप्लिकेशन कोड के माध्यम से। JSONB कुछ भी स्टोर कर सकता है, जो कि तब समस्या बन जाता है जब आपको मजबूत गारंटीज़ चाहिए।

संकेत जो बताते हैं कि अब आपको नॉर्मलाइज़ करना चाहिए

आमतौर पर JSON-प्रथम मॉडल से हटने का समय तब होता है जब इनमें से कई सच हों:

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

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

एक ठोस उदाहरण

एक प्रोटोटाइप "customer requests" को JSONB में स्टोर करता है क्योंकि हर अनुरोध प्रकार के अलग फ़ील्ड होते हैं। बाद में, ऑपरेशंस को प्रायरिटी और SLA द्वारा फ़िल्टर किया हुआ एक क़्यू चाहिए। फाइनेंस को विभाग के हिसाब से टोटल चाहिए। सपोर्ट को यह गारंटी चाहिए कि हर रिक्वेस्ट में customer ID और status हो। यही जगह है जहाँ normalized टेबल्स चमकते हैं: सामान्य फ़ील्ड्स के लिए स्पष्ट कॉलम, customers और teams के लिए फॉरेन कीज़, और खराब डेटा को रोकने के लिए कंस्ट्रेंट्स।

30 मिनट में उपयोग करने के लिए एक साधारण निर्णय ढाँचा

आपको बड़े डेटाबेस थ्योरी पर बहस की ज़रूरत नहीं है। आपको एक तेज़, लिखित जवाब चाहिए एक सवाल पर: कहाँ फ्लेक्सिबिलिटी सख्त संरचना से अधिक मूल्यवान है?

यह काम उस लोगों के साथ करें जो सिस्टम बनाते और उपयोग करते हैं (बिल्डर, ऑप्स, सपोर्ट, और शायद फाइनेंस)। लक्ष्य एक विजेता चुनना नहीं है। लक्ष्य यह है कि उत्पाद के हर हिस्से के लिए उपयुक्त फिट चुनें।

5-स्टेप चेकलिस्ट

1. अपनी 10 सबसे महत्वपूर्ण स्क्रीन और उनके पीछे के ठीक सवालों को सूचीबद्ध करें। उदाहरण: "एक ग्राहक रिकॉर्ड खोलें", "ओवरड्यू ऑर्डर ढूँढें", "पिछले महीने के पाउट्स एक्सपोर्ट करें"। अगर आप सवाल का नाम नहीं बता सकते तो आप उसके लिए डिज़ाइन नहीं कर सकते।

2. उन फ़ील्ड्स को हाइलाइट करें जो हर बार सही होने चाहिए। ये कठोर नियम हैं: स्थिति, राशियाँ, तिथियाँ, स्वामित्व, अनुमतियाँ। अगर गलत मान से पैसा टूट सकता है या सपोर्ट संकट उठ सकता है, तो ये आम तौर पर सामान्य कॉलम और कंस्ट्रेंट्स में होने चाहिए।

3. जो अक्सर बदलता है बनाम जो शायद ही बदलता है उसे मार्क करें। साप्ताहिक बदलाव (नए फॉर्म प्रश्न, पार्टनर-विशिष्ट विवरण) मजबूत JSONB उम्मीदवार हैं। कम बदलने वाले "कोर" फ़ील्ड्स normalized की ओर झुकते हैं।

4. तय करें क्या UI में सर्चेबल, फ़िल्टरेबल, या सॉर्टेबल होना चाहिए। अगर उपयोगकर्ता लगातार उस पर फ़िल्टर करते हैं तो यह आम तौर पर पहले-श्रेणी कॉलम (या सावधानीपूर्वक इंडेक्स किए गए JSONB पाथ) के रूप में बेहतर है।

5. हर एरिया के लिए एक मॉडल चुनें। सामान्य विभाजन है: कोर एंटिटीज़ और वर्कफ़्लोज़ के लिए normalized टेबल्स, और एक्स्ट्राज व तेज़ी से बदलने वाले मेटाडेटा के लिए JSONB।

प्रदर्शन के मूल बातें बिना डिटेल्स में खोए

स्पीड आम तौर पर एक बात से आती है: आपके सबसे सामान्य सवालों को सस्ता बनाना। यह विचारधारा से ज्यादा मायने रखता है।

अगर आप JSONB का उपयोग करते हैं, तो उसे छोटा और अनुमाननीय रखें। कुछ अतिरिक्त फ़ील्ड ठीक हैं। एक विशाल, हमेशा बदलते हुए ब्लॉब को इंडेक्स करना मुश्किल है और गलत इस्तेमाल के लिए आसान है। अगर आप जानते हैं कि कोई की मौजूद रहेगी (जैसे "priority" या "source"), तो की का नाम और मान का प्रकार सुसंगत रखें।

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

इंडेक्सिंग के सामान्य नियम

• सामान्य फ़िल्टर्स जैसे status, owner_id, created_at, updated_at पर सामान्य btree इंडेक्स रखें।
• जब आप अक्सर JSONB के अंदर खोज करते हैं तो JSONB कॉलम पर GIN इंडेक्स का उपयोग करें।
• एक या दो हॉट JSON फ़ील्ड के लिए एक्सप्रेशन इंडेक्स पसंद करें (जैसे (meta->>'priority')) बजाय पूरे JSONB को इंडेक्स करने के।
• जब केवल एक स्लाइस मायने रखता है तो पार्टियल इंडेक्स का उपयोग करें (उदाहरण के लिए केवल उन रो के लिए जहाँ status = 'open')।

JSONB के अंदर नंबर और तिथियाँ स्ट्रिंग के रूप में स्टोर करने से बचें। "10" "2" से पहले सॉर्ट करेगा, और डेट गणित परेशानी बन जाएगी। असली न्यूमेरिक और टाइमस्टैम्प टाइप्स कॉलम में रखें, या कम से कम JSON में संख्याओं को नंबर के रूप में स्टोर करें।

एक हाइब्रिड मॉडल अक्सर जीतता है: कोर फ़ील्ड्स कॉलम्स में, फ्लेक्सिबल एक्स्ट्राज JSONB में। उदाहरण: एक operations टेबल जिसमें id, status, owner_id, created_at कॉलम के रूप में और meta JSONB ऑप्शनल जवाबों के लिए।

आम गलतियाँ जो बाद में दर्द देती हैं

शुरू में JSONB आज़ादी जैसा लग सकता है। दर्द आमतौर पर महीनों बाद दिखता है, जब अधिक लोग डेटा को छूते हैं और “जो काम करता है” बदलकर “हम किसी बदलाव के बिना इसे बदल नहीं सकते” बन जाता है।

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

• JSONB को डंपिंग ग्राउंड मानना। अगर हर टीम थोड़ा अलग शेप स्टोर करे तो आप हर जगह कस्टम पार्सिंग लॉजिक लिखते हुए पाएँगे। बुनियादी कन्वेंशन्स सेट करें: लगातार की-नाम, स्पष्ट तिथि फॉर्मैट, और JSON के अंदर छोटा वर्शन फ़ील्ड।
• JSONB के अंदर कोर एंटिटीज़ छुपाना। ग्राहक, ऑर्डर, या अनुमतियाँ केवल ब्लॉब के रूप में स्टोर करने से शुरुआत में सरल लगता है पर बाद में जॉइन्स अजीब हो जाते हैं, कंस्ट्रेंट्स लागू करना मुश्किल होता है, और डुप्लिकेट्स उभरते हैं। कौन/क्या/कब को कॉलम्स में रखें, और वैकल्पिक विवरण JSONB में रखें।
• माइग्रेशन के बारे में तब तक नहीं सोचना जब तक यह जरूरी न हो। अगर आप यह ट्रैक नहीं करते कि कौन सी कीज़ मौजूद हैं, कैसे बदलीं, और कौन सी “ओफ़िशियल” हैं, तो आपका पहला असली माइग्रेशन जोखिमभरा बन जाता है।
• यह मान लेना कि JSONB अपने आप लचीला और तेज़ है। नियमों के बिना लचीलापन बस असंगतता है। स्पीड एक्सेस पैटर्न और इंडेक्सेस पर निर्भर करती है।
• समय के साथ कीज़ बदलकर एनालिटिक्स तोड़ देना। status को state में नाम बदलना, नंबरों को स्ट्रिंग में बदलना, या टाइमज़ोन मिक्स करना रिपोर्ट्स को चुपचाप नष्ट कर देगा।

एक ठोस उदाहरण: एक टीम tickets टेबल और एक details JSONB फ़ील्ड के साथ शुरू करती है फॉर्म उत्तरों के लिए। बाद में, फाइनेंस को कैटेगरी के हिसाब से साप्ताहिक ब्रेकडाउन चाहिए, ऑपरेशंस को SLA ट्रैकिंग चाहिए, और सपोर्ट को "team द्वारा ओपन" डैशबोर्ड चाहिए। अगर कैटेगरी और टाइमस्टैम्प्स कीज़ और फ़ॉर्मैट्स में ड्रिफ्ट करते हैं, तो हर रिपोर्ट एक-ऑफ़ क्वेरी बन जाती है।

जब प्रोटोटाइप मिशन-क्रिटिकल बन जाए तो माइग्रेशन प्लान

जब प्रोटोटाइप पे-रोल, इन्वेंटरी, या कस्टमर सपोर्ट संभालने लगे, तो "हम बाद में डेटा ठीक कर लेंगे" स्वीकार्य नहीं रहता। सबसे सुरक्षित रास्ता छोटे कदमों में माइग्रेट करना है, ताकि पुराना JSONB डेटा तब भी काम करता रहे जब नया स्ट्रक्चर परख रहा हो।

एक चरणबद्ध अप्रोच जोखिमपूर्ण बिग-बैंग रीव्राइट से बचाती है:

• पहले गंतव्य डिज़ाइन करें। लक्ष्य तालिकाएँ, प्राथमिक कुंजी और नामकरण नियम लिखें। तय करें क्या असली एंटिटी है (Customer, Ticket, Order) और क्या लचीला रहेगा (notes, optional attributes)।
• पुराने डेटा के बगल में नई तालिकाएँ बनाएं। JSONB कॉलम रखें, नए normalized टेबल्स और इंडेक्स समानांतर जोड़ें।
• बैचों में बैकफिल और वैलिडेट करें। JSONB फ़ील्ड्स को नए टेबल्स में हिस्सों में कॉपी करें। रो काउंट्स, आवश्यक फ़ील्ड्स नुल न हों, और स्पॉट चेक्स के साथ वैलिडेशन करें।
• पहले पढ़ाई स्विच करें फिर लिखाई। क्वेरीज और रिपोर्ट्स को पहले नए टेबल्स से पढ़ने के लिए अपडेट करें। जब आउटपुट मिल जाएँ तो नई बदलियां normalized टेबल्स में लिखना शुरू करें।
• लॉक डाउन करें। JSONB में लिखना रोक दें, फिर पुराने फ़ील्ड्स को डिलीट या फ्रीज़ करें। फॉरेन कीज़ और यूनिक नियम जोड़ें ताकि खराब डेटा वापस ना आए।

अंतिम कटओवर से पहले:

• दोनों पाथ्स एक हफ्ते चलाएँ (पुराना बनाम नया) और आउटपुट की तुलना करें।
• धीमी क्वेरीज मॉनिटर करें और जहाँ चाहिए इंडेक्स जोड़ें।
• रोलबैक योजना तैयार रखें (फीचर फ्लैग या कंफिग स्विच)।
• टीम को लिखाई-स्विच का सटीक समय कम्युनिकेट करें।

फ़ाइनल करने से पहले तेज़ जाँच

अप approach लॉक करने से पहले एक वास्तविकता जांच करें। ये सवाल परिवर्तन अभी सस्ता रहते हुए अधिकांश भविष्य की समस्याएँ पकड़ लेते हैं।

पाँच सवाल जो अधिकांश परिणाम तय करते हैं

• क्या हमें अभी (या अगले रिलीज़ में) यूनिकनेस, आवश्यक फ़ील्ड्स, या सख्त टाइप्स चाहिए?
• कौन से फ़ील्ड्स UI में फिल्टरेबल और सॉर्टेबल होना चाहिए (सर्च, स्थिति, मालिक, तिथियाँ)?
• क्या हमें जल्द ही डैशबोर्ड्स, एक्सपोर्ट्स या "finance/ops को भेजे जाने" वाले रिपोर्ट्स चाहिए?
• क्या हम अपने डेटा मॉडल को किसी नए साथी को 10 मिनट में समझा सकते हैं बिना बहाने के?
• यदि माइग्रेशन किसी वर्कफ़्लो को तोड़ दे तो हमारा रोलबैक प्लान क्या है?

यदि आप पहले तीन प्रश्नों में “हाँ” कहते हैं, तो आप पहले से ही normalized टेबल्स की ओर झुक रहे हैं (या कम से कम हाइब्रिड: कोर फ़ील्ड्स normalized और लंबी-पुंछ गुण JSONB में)। अगर केवल आखिरी प्रश्न का जवाब "हाँ" है, तो आपकी बड़ी समस्या प्रोसेस है, स्कीमा नहीं।

एक सरल अंगूठा का नियम

जब डेटा की शेप अस्पष्ट हो पर आप कुछ छोटे स्थिर फ़ील्ड्स नामित कर सकते हैं (जैसे id, owner, status, created_at), तब JSONB का उपयोग करें। जिस क्षण लोग लगातार फ़िल्टर, भरोसेमंद एक्सपोर्ट या सख्त वैलिडेशन पर निर्भर करते हैं, "लचीलापन" की लागत तेज़ी से बढ़ जाती है।

उदाहरण: एक लचीले फॉर्म से भरोसेमंद ऑपरेशंस सिस्टम तक

कल्पना करें एक कस्टमर सपोर्ट intake फॉर्म जिसकी संरचना साप्ताहिक बदलती है। एक हफ्ता आप "device model" जोड़ते हैं, अगले हफ्ते "refund reason" जोड़ते हैं, फिर आप "priority" को "urgency" नाम दे देते हैं। शुरुआत में फॉर्म पेलोड को एक JSONB कॉलम में रखना परफेक्ट लगता है। आप बिना माइग्रेशन के बदलाव भेज सकते हैं, और कोई शिकायत नहीं करता।

तीन महीने बाद, मैनेजर चाहते हैं ऐसे फ़िल्टर: "urgency = high और device model iPhone से शुरू होता है", SLAs कस्टमर टियर पर आधारित हों, और साप्ताहिक रिपोर्ट पिछले सप्ताह की संख्या से मिलनी चाहिए।

फेल्यर मोड अनुमानित है: किसी ने पूछा, "यह फ़ील्ड कहाँ गया?" पुराने रिकॉर्ड्स में अलग की-नाम इस्तेमाल हुआ, मान का प्रकार बदला ("3" बनाम 3), या फ़ील्ड आधे टिकट्स के लिए अस्तित्व में ही नहीं था। रिपोर्ट्स स्पेशल-केस क्वेरीज की पैचवर्क बन जाती हैं।

एक व्यावहारिक मध्य मार्ग हाइब्रिड डिज़ाइन है: स्थिर, व्यापार-आवश्यक फ़ील्ड्स को असली कॉलम्स के रूप में रखें (created_at, customer_id, status, urgency, sla_due_at), और नए या दुर्लभ फ़ील्ड्स के लिए JSONB एक्सटेंशन एरिया रखें।

एक कम-बाधा टाइमलाइन जो अच्छा काम करती है:

• सप्ताह 1: 5–10 फ़ील्ड चुनें जिन्हें फिल्टर और रिपोर्टेबल होना चाहिए। कॉलम जोड़ें।
• सप्ताह 2: हाल के रिकॉर्ड्स से पहले उन कॉलम्स को JSONB से बैकफिल करें, फिर पुराने रिकॉर्ड्स।
• सप्ताह 3: नई रिकॉर्ड्स को अस्थायी रूप से दोनों (कॉलम्स और JSONB) में लिखें (डबल-राइट)।
• सप्ताह 4: पढ़ाई और रिपोर्ट्स को कॉलम्स पर स्विच करें। JSONB केवल एक्स्ट्राज के लिए रखें।

अगले कदम: निर्णय लें, दस्तावेज़ करें, और बनाते रहें

अगर आप कुछ न करें, तो निर्णय अपने आप ले लिया जाएगा। प्रोटोटाइप बढ़ता है, किनारे कठोर होते हैं, और हर बदलाव जोखिमभरा लगने लगता है। बेहतर कदम यह है कि अभी एक छोटा लिखित निर्णय लें, फिर बनाते रहें।

अपने ऐप के 5–10 सवालों की सूची बनाएं जिन्हें आप तेज़ी से जवाब देना चाहते हैं ("इस ग्राहक के सभी खुले ऑर्डर दिखाएँ", "ईमेल से यूज़र्स ढूँढें", "महीने के हिसाब से राजस्व रिपोर्ट करें"). हर एक के बगल में वे कंस्ट्रेंट्स लिखें जिन्हें आप तोड़ना नहीं चाहेंगे (यूनिक ईमेल, आवश्यक स्थिति, वैध टोटल)। फिर एक स्पष्ट सीमा निर्धारित करें: JSONB उन फ़ील्ड्स के लिए रखें जो अक्सर बदलते हैं और जिन्हें शायद ही फ़िल्टर या जॉइन किया जाता है, और कॉलम्स/टेबल्स में प्रमोट करें जो आप सर्च, सॉर्ट, जॉइन या हर बार वैलिडेट करना चाहते हैं।

यदि आप किसी नो-कोड प्लेटफ़ॉर्म का उपयोग कर रहे हैं जो वास्तविक एप्लिकेशंस जेनरेट करता है, तो यह विभाजन समय के साथ प्रबंधित करना आसान कर सकता है। उदाहरण के लिए, AppMaster (appmaster.io) आपको PostgreSQL तालिकाएँ विजुअली मॉडल करने देता है और आवश्यकताओं के बदलने पर अंडरलाइनिंग बैकएंड और ऐप्स को पुनरजनरेट करने की सुविधा देता है, जो इटरेटिव स्कीमा बदलाव और योजनाबद्ध माइग्रेशंस को कम दर्दनाक बनाता है।