PostgREST: उत्पादन में बेंचमार्क और वास्तविक सीमाएँ

यह अंग्रेजी पाठ फ़्रेंच मूल से स्वचालित रूप से उत्पन्न हुआ था और अभी तक इसकी समीक्षा नहीं की गई है।

यह पृष्ठ स्वचालित रूप से अनुवादित किया गया था. अंग्रेजी संस्करण प्रामाणिक है.

PostgREST संगतता पर हमारा लेख बताता है कि सर्वर कार्यात्मक रूप से क्या कवर करता है (फ़िल्टर, एम्बेडिंग, आरपीसी, आरएलएस) और यह आप पर क्या छोड़ता है। यह कहीं और से आता है. यह स्रोत के रूप में ऑराबेस कोड और आधिकारिक PostgREST दस्तावेज़ के साथ दस्तावेज करता है, जहां और क्यों PostgREST वास्तव में बड़े पैमाने पर पठार है। हम यहां कोई लोड बैंक नहीं बना रहे हैं जिसे हमने स्वयं नहीं चलाया है। हमारी बेंचमार्क कार्यप्रणाली बताती है कि प्रकाशित प्रोटोकॉल के बिना एक पृथक आंकड़ा हमें विश्वसनीय क्यों नहीं लगता है।

अनिवार्य है

PostgREST स्वयं हल्का है: समर्पित Aurabase उदाहरणों पर प्रति प्रतिकृति 50 से 250 मिली सीपीयू, 64 से 128 एमबी रैम। कच्चा HTTP थ्रूपुट लगभग कभी भी उत्पादन को सीमित करने वाला कारक नहीं होता है।
वास्तविक सीमा पोस्टग्रेज कनेक्शन बजट है: PGRST_DB_POOL × प्रतिकृतियां। ऑराबेस कोड में सत्यापित: समर्पित स्तर (10×2) पर प्रति प्रोजेक्ट 20 कनेक्शन, साझा स्तर (2×2) पर 4 कनेक्शन। यह उसी max_connectionsपर अधिक किरायेदारों को शामिल करने के लिए एक जानबूझकर किया गया विकल्प है।
Prefer: count=exact बड़ी मेजों पर महंगी MVCC स्कैनिंग को बाध्य करता है। PostgREST दस्तावेज़ दो सस्ते विकल्प: count=planned और count=estimated, जिनकी कुल लागत अनुमानित है।
एक db-max-rows सीलिंग (Aurabase पर डिफ़ॉल्ट रूप से 1000 लाइनें) किसी प्रतिक्रिया को Content-Range में रिपोर्ट किए बिना छोटा कर देती है (वास्तविक स्थितियों में मापा जाता है, जिसका विवरण नीचे दिया गया है)।
DDL माइग्रेशन के बाद, PostgREST स्कीमा कैश अतुल्यकालिक रूप से पुनः लोड होता है। ऑराबेस गेटवे हार मानने से पहले 8 बार (सबसे खराब स्थिति में लगभग 3.5 सेकंड संचयी) तक पुनः प्रयास करता है, यह व्यवहार सीधे कोड में दर्ज किया गया है।

क्रियाविधि

PostgREST बेंचमार्क क्या मापता है, और क्या नहीं मापता है

PostgREST पर एक HTTP थ्रूपुट परीक्षण मुख्य रूप से Postgres को मापता है, शायद ही कभी PostgREST को। सर्वर आधार के सामने अनुवाद की एक पतली परत है। वास्तविक दुनिया के अधिकांश लोड में, प्रतिक्रिया समय निष्पादित SQL क्वेरी पर हावी होता है, न कि उस प्रक्रिया पर जिसने इसे उत्पन्न किया है।

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

PostgREST के नीचे, यह pgbench है जो उस परत को मापता है जो वास्तव में मायने रखती है: समवर्ती लोड के तहत SQL लेनदेन समय। यह आधिकारिक PostgreSQL बेंचमार्क टूल है (postgresql.org/docs/current/pgbench.html, 24 अगस्त 2026 को एक्सेस किया गया)। इस प्रोटोकॉल को यहां पुन: प्रस्तुत करने के बजाय, यह लेख उत्पादन में PostgREST की चार ठोस वास्तुशिल्प सीमाओं का दस्तावेजीकरण करता है, प्रत्येक को ऑराबेस स्रोत कोड या आधिकारिक परियोजना दस्तावेज़ीकरण में सत्यापित किया गया है।

कोड में चेक किया गया

Aurabase पर PostgREST उदाहरण का वास्तविक पदचिह्न

प्रत्येक Aurabase Postgres इंजन प्रोजेक्ट को दो समर्पित PostgREST प्रतिकृतियां प्राप्त होती हैं, जो उसके क्लस्टर के साथ सह-स्थित होती हैं। कुबेरनेट्स मेनिफेस्ट जो उन्हें तैनात करता है वह मामूली संसाधन निर्धारित करता है।

50-250m

प्रति प्रतिकृति सीपीयू

अनुरोध → सीमाएँ

64-128

प्रति प्रतिकृति एमबी रैम

अनुरोध → सीमाएँ

परियोजना द्वारा प्रतिकृतियां

उच्च उपलब्धता (P22)

ये प्रतिकृतियां वास्तव में जो उपभोग करती हैं वह सीपीयू नहीं है: वे पोस्टग्रेज प्राथमिक से कनेक्शन हैं। प्रत्येक PostgREST उदाहरण किरायेदार के लिए तैनात PgBouncer पूलर से गुजरे बिना सीधे प्राथमिक (-rw) से जुड़ता है। यह विकल्प पहले से ही PostgREST संगततापर हमारे लेख में विस्तृत है: LISTEN/NOTIFY स्कीमा रीलोडिंग तंत्र को एक सतत कनेक्शन की आवश्यकता होती है, जो लेनदेन मोड में पूलर के साथ असंगत है। यह लेख क्या जोड़ता है: वास्तव में इसकी लागत कितनी है, कनेक्शन के संदर्भ में, और यह कहां चरम पर है।

इस पूल का आकार प्रति प्रतिकृति (PGRST_DB_POOL) जानबूझकर प्रोजेक्ट स्तर के आधार पर भिन्न होता है, जिसे k8s_tenant.rsमें सत्यापित किया गया है, वह फ़ंक्शन जो प्रत्येक प्रोजेक्ट के लिए PostgREST मेनिफेस्ट बनाता है:

सहन करना	PGRST_DB_POOL / प्रतिकृति	प्रतिकृतियां	कनेक्शन/जागृत परियोजना
समर्पित (प्रीमियम, A1)	10 (पोस्टग्रेस्ट डिफ़ॉल्ट)	2	20
साझा (बेड़ा, मुफ़्त/समर्थक/टीम)	2 (ऑराबेस डिफ़ॉल्ट, कम किया गया)	2	4

deploy/cnpg/tenant-postgrest.yaml (वास्तविक उद्धरण, प्रावधानकर्ता द्वारा प्रतिस्थापित मूल्य)yaml

# प्राथमिक पर प्रति प्रतिकृति कनेक्शन का फ़िंगरप्रिंट।
env:
  - { name: PGRST_DB_POOL, value: "PGRST_DB_POOL_VALUE" }  # 10 (समर्पित) या 2 (साझा)

समर्पित स्तर पर, बाधा में ढील दी गई है: एक परियोजना का अपना सीएनपीजी क्लस्टर है, इसलिए इसका अपना max_connectionsहै, जिसमें कोई पड़ोसी नहीं है। साझा स्तर पर, एक ही संगठन की कई परियोजनाएं एक ही क्लस्टर साझा करती हैं: यह वह संदर्भ है जो कनेक्शन बजट को निर्णायक बनाता है, जिसे निम्नलिखित अनुभाग में विकसित किया गया है।

असली छत

कनेक्शन बजट यह तय करता है कि एक ही समय में कितने किरायेदार काम कर रहे हैं

साझा पोस्टग्रेज क्लस्टर पर, यह HTTP थ्रूपुट नहीं है जो एक साथ सक्रिय परियोजनाओं की संख्या को सीमित करता है। यह उपलब्ध max_connectionsकी तुलना में, उनके PostgREST इंस्टेंसेस के प्राथमिक पर खुले कनेक्शनों की संख्या है।

ऑराबेस इस बजट को सीधे वास्तविक क्लस्टर सीमा से प्राप्त करता है, जिसे fleet.rs: (max_connections − réserve superuser/CNPG − connexions réservées au pooler) ÷ connexions par projet éveilléमें चेक किया गया है, फ्लोर 1 पर। निश्चित रिजर्व 10 कनेक्शन (सुपरयूजर, सीएनपीजी इंस्टेंस मैनेजर, मेट्रिक्स एक्सपोर्टर, प्रोविजनर एडमिन मार्जिन) है। वितरित दोषों पर (2 प्रति प्रतिकृति, 2 प्रतिकृतियां, या 4 कनेक्शन प्रति जागृत परियोजना का पूल), गणना क्लस्टर के आकार स्तर के आधार पर तीन अलग-अलग बजट देती है।

स्रोत: fleet.rs::derive_wake_budget और wake_budget_for_org_planसे प्राप्त, ऑराबेस कोड, 24 अगस्त, 2026 को पुनः पढ़ा गया।

यह बजट स्वामित्व वाली परियोजनाओं का कोटा नहीं है: एक team संगठन 50 परियोजनाएं रख सकता है, जिनमें से अधिकांश निष्क्रिय हैं। यह समवर्तीता की सीमा है: उन परियोजनाओं की संख्या जो प्राथमिक पर एक ही समय में खुले कनेक्शन रख सकती हैं। बजट को लेकर जागरुकता विफल नहीं होती है, इसे तब तक के लिए स्थगित कर दिया जाता है जब तक कि एक सहोदर परियोजना वापस सो नहीं जाती, उसी फ़ाइल में जाँच की जाती है। max_connections को आकार देने के विषय का विस्तार हमारे लेख में max_connectionsकी ट्यूनिंग और समर्पित बनाम साझा आधारमें समग्र रूप से समर्पित/पारस्परिक ट्रेडऑफ़ में किया गया है।

छिपी हुई लागत

क्यों प्राथमिकता दें: count=exact एक बड़ी तालिका पर क्वेरी को धीमा कर देता है

सटीक कुल के लिए पूछना पोस्टग्रेज को प्रत्येक क्वेरी के साथ फ़िल्टर किए गए परिणाम की दृश्यमान पंक्तियों को गिनने के लिए मजबूर करता है, एक लागत जो तालिका के साथ बढ़ती है, एक मुफ्त ऑपरेशन नहीं।

PostgreSQL बॉक्स के बाहर किसी भी अनुक्रमित पंक्ति काउंटर को बनाए नहीं रखता है। एमवीसीसी के तहत, एक पंक्ति की दृश्यता उस लेनदेन पर निर्भर करती है जो इसे पढ़ता है। इसलिए सटीक COUNT(*) को पूर्व-गणना किए गए मान को पढ़ने के बजाय उम्मीदवार पंक्तियों पर जाना चाहिए। यह पोस्टग्रेज पारिस्थितिकी तंत्र में एक अच्छी तरह से प्रलेखित संरचनात्मक सीमा है, जिसमें क्लिकहाउस जैसे एनालिटिक्स विक्रेता शामिल हैं, जो अपने स्वयं के अनुमानित काउंटरों की तुलना पोस्टग्रेज लेनदेन व्यवहार से करते हैं।

terminalbash

# बड़ी मेज पर महँगा: फ़िल्टर किए गए परिणाम के एमवीसीसी स्कैन को बाध्य करता है
curl "https://<gateway>/v1/db/<project_id>/orders?status=eq.paid" \
  -H "apikey: <clé>" -H "Prefer: count=exact"

# कम महंगे विकल्प, PostgREST द्वारा प्रलेखित
  -H "Prefer: count=planned"   # योजनाकार के माध्यम से अनुमान
  -H "Prefer: count=estimated" # एक सीमा से परे की योजना बनाई गई, बिल्कुल नीचे

PostgREST इन तीन गिनती रणनीतियों को मूल रूप से दस्तावेज़ित करता है (postgrest.org, 24 अगस्त, 2026 को एक्सेस किया गया)। exact रणनीति स्कैन की कीमत पर कुल गारंटी देती है। planned क्वेरी प्लानर से लगभग निःशुल्क अनुमान लौटाता है। estimated थ्रेशोल्ड के आधार पर स्वचालित रूप से दोनों के बीच स्विच हो जाता है। विकल्प कॉस्मेटिक नहीं है: एक पृष्ठांकन जिसके लिए कई मिलियन पंक्तियों की तालिका पर count=exact की आवश्यकता होती है, प्रत्येक पृष्ठ पर इस स्कैन के लिए भुगतान करता है, तब भी जब उपयोगकर्ता कभी भी अंतिम से परामर्श नहीं करता है।

वास्तविक रूप से मापा गया

डीबी-मैक्स-पंक्तियों का कटाव गिनती=सटीक के बिना अदृश्य है

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

PGRST_DB_MAX_ROWS=5के साथ 10-पंक्ति परीक्षण तालिका पर, PostgREST v12.2.3 दो अलग-अलग स्थितियों के लिए बिल्कुल समान Content-Range हेडर प्रस्तुत करता है:

सवाल	प्रस्तुत पंक्तियाँ	सामग्री रेंज	मेटा (औराबेस)
?सीमा=50 (बिना गिनती के)	5/10 असली	0-4/*	{}
?सीमा=50&गिनती=सटीक	5/10 असली	0-4/10	{कुल: 10}

count=exactके बिना, 5 पंक्तियों की प्रतिक्रिया उस तालिका से अप्रभेद्य है जिसमें वास्तव में केवल 5 होंगे: Content-Range: 0-4/* प्रस्तुत पंक्तियों का वर्णन करता है, कभी भी लागू सीमा का वर्णन नहीं करता है। इस मामले में वास्तविक सीमा कहीं भी दिखाई नहीं देती है, इसे सीधे ऑराबेस एसडीके के पोस्टग्रेस्ट पथ पर मापा जाता है।

PostgREST पर किसी भी पेजिनेशन का परिणाम

यदि आपका PostgREST परिनियोजन db-max-rows (Aurabase डिफ़ॉल्ट रूप से 1000) सेट करता है, तो एक क्लाइंट जो पूर्ण पृष्ठ का पता लगाने के लिए data.length की अनुरोधित सीमा से तुलना करता है, वह गलत हो सकता है। जैसे ही सर्वर सीलिंग इस सीमा से कम होती है, त्रुटि प्रकट हो जाती है। एकमात्र विश्वसनीय संकेत count=exactद्वारा लौटाए गए total से प्राप्त लाइनों की संख्या की तुलना करना है, जो सीधे पिछले अनुभाग में वर्णित लागत व्यापार-बंद को खेल में लाता है।

विलंबित विलंबता

माइग्रेशन के बाद स्कीमा कैश को पुनः लोड करना

PostgREST स्टार्टअप पर पोस्टग्रेज स्कीमा को मेमोरी में रखता है। डीडीएल (तालिका बनाएं, कॉलम जोड़ें) के बाद, नए रूट के प्रतिक्रिया देने से पहले इस कैश को पुनः लोड किया जाना चाहिए, और यह पुनः लोड अतुल्यकालिक है।

इस विंडो में आने वाले लेखन को एक क्षणिक 404 (कैश अभी तक अद्यतित नहीं) प्राप्त हो सकता है, भले ही तालिका वास्तव में पोस्टग्रेज पक्ष पर मौजूद हो। ऑराबेस गेटवे इसे एक सीमित रिट्री लूप के साथ अवशोषित करता है, जिसे postgrest_proxy.rsमें सत्यापित किया गया है: 8 प्रयासों तक, बैकऑफ़ बढ़ाना (250 एमएस प्लस 100 एमएस प्रति प्रयास), सबसे खराब स्थिति में 3.5 सेकंड संचयी। यह तंत्र केवल लिखने को प्रभावित करता है, पढ़ने को कभी नहीं।

एक विवरण जिसे कोड स्वयं प्रलेखित करता है

गेटवे कोई पुनः लोड सिग्नल उत्सर्जित नहीं करता है: यह केवल प्रतीक्षा करता है। एकमात्र वास्तविक ट्रिगर DDL पथ पर डेटाबेस सेवा द्वारा जारी किया गया pg_notify('pgrst', 'reload schema') है। यदि कोई माइग्रेशन पथ इस सिग्नल को उत्सर्जित करना भूल जाता है, तो 8 प्रयास कैश पर समाप्त हो जाते हैं जो कभी नहीं बदलेगा, एक जोखिम जैसा कि कोड टिप्पणी में दर्ज किया गया है, छिपा हुआ नहीं है।

स्व-होस्ट किए गए PostgREST परिनियोजन के लिए, पाठ सामान्यीकृत होता है। आपके एप्लिकेशन में प्रत्येक DDL पथ को प्रक्रिया के लिए NOTIFY या SIGUSR1 सिग्नल के माध्यम से पुनः लोड को ट्रिगर करना चाहिए। अन्यथा, एक माइग्रेशन तैनाती के ठीक बाद रुक-रुक कर होने वाली त्रुटियों के रूप में प्रच्छन्न एक p99 विलंबता स्पाइक उत्पन्न करता है।

सारांश

आर्किटेक्चर क्या काटता है, कच्चा थ्रूपुट नहीं

यहां प्रलेखित चार सीमाएं एक बात साझा करती हैं: एक अलग HTTP थ्रूपुट परीक्षण पर कोई भी नहीं देखा जाता है, फिर भी सभी चार यह निर्धारित करते हैं कि क्या PostgREST परिनियोजन उत्पादन के पैमाने पर है।

कनेक्शन बजट: प्रति किरायेदार थ्रूपुट की परवाह किए बिना, साझा क्लस्टर पर एक साथ सक्रिय किरायेदारों की संख्या को सीमित करता है।
सटीक COUNT की लागत: टेबल के साथ बढ़ती है, भार के साथ नहीं; planned/estimatedसे बायपास किया गया है।
साइलेंट ट्रंकेशन: एक सही ढंग से कॉन्फ़िगर किया गया पंक्ति कैप अभी भी खराब उपकरण वाले पेजिंग को तोड़ सकता है।
स्कीमा पुनः लोड: प्रत्येक माइग्रेशन के बाद एक विलंबता विंडो, यदि पुनः लोड सिग्नल अच्छी तरह से वायर्ड है तो सीमित, अन्यथा असीमित।

चाहे आप स्वयं-होस्ट किए गए PostgREST, एक हसुरा-शैली ग्राफक्यूएल परत, या एक कस्टम एपीआई के बीच चयन कर रहे हों, ये चार अक्ष एक अलग req/s आंकड़े की तुलना में तुलना का एक बेहतर बिंदु हैं। हमारी तुलना देखें PostgREST बनाम हसुरा बनाम कस्टम API। आपके डेटाबेस के सामने खड़े पूलर का चुनाव भी उतना ही मायने रखता है: हमारी तुलना PgBouncer बनाम Supavisor बनाम PgCat बताती है कि PostgREST लेनदेन मोड में पूलर के माध्यम से क्यों नहीं जा सकता है।

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

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

क्या PostgREST बड़े पैमाने पर उत्पादन के लिए पर्याप्त तेज़ है?+

PostgREST अपने आप में एक हल्की प्रक्रिया है। समर्पित ऑराबेस उदाहरणों पर, एक प्रतिकृति 50 से 250 मिलीकोर सीपीयू और 64 से 128 एमबी रैम के साथ चलती है, जो परियोजना के कुबेरनेट्स मेनिफेस्ट में सत्यापित है। कच्चा HTTP थ्रूपुट लगभग कभी भी उत्पादन को सीमित करने वाला कारक नहीं होता है। यह पोस्टग्रेज कनेक्शन बजट, सटीक COUNT की लागत और स्कीमा कैश है जो यह निर्धारित करता है कि क्या पूरी चीज मापी जाती है, न कि अकेले पोस्टग्रैस्ट बाइनरी की गति।

मुझे कैसे पता चलेगा कि मेरी PostgREST प्रतिक्रिया को db-max-rows द्वारा छोटा कर दिया गया है?+

PostgREST द्वारा लौटाया गया कंटेंट-रेंज हेडर यह कभी नहीं कहता है। प्रति डीबी-मैक्स-पंक्तियों पर 5 पंक्तियों पर छाया हुआ एक प्रतिक्रिया उस तालिका से अप्रभेद्य है जिसमें वास्तव में केवल 5 होते हैं, जो एक समर्पित ऑराबेस उदाहरण पर वास्तविक स्थितियों में मापा जाता है। इसका पता लगाने का एकमात्र विश्वसनीय तरीका प्राप्त लाइनों की संख्या की तुलना प्रेफ़र द्वारा लौटाए गए कुल से करना है: गिनती = सटीक, इस हेडर के बिना ट्रंकेशन अदृश्य रहता है।

क्या सटीक COUNT हमेशा PostgREST अनुरोध को धीमा कर देता है?+

प्राथमिकता: गिनती=सटीक प्रत्येक क्वेरी के साथ फ़िल्टर किए गए परिणाम की दृश्यमान पंक्तियों को गिनने के लिए पोस्टग्रेज़ को बाध्य करता है, एक लागत जो एमवीसीसी के कारण तालिका आकार के साथ बढ़ती है। पोस्टग्रेज़ बॉक्स के बाहर अनुक्रमित पंक्ति काउंटर बनाए नहीं रखता है। PostgREST दो कम महंगे विकल्प प्रदान करता है, गिनती = नियोजित (अनुसूचक के माध्यम से अनुमान) और गिनती = अनुमानित (एक सीमा से परे स्वचालित स्विचिंग), जो इसके आधिकारिक दस्तावेज में दर्ज है।

PostgREST कितने Postgres कनेक्शन का उपभोग करता है?+

यह पूरी तरह से प्रतिकृतियों की संख्या से गुणा किए गए PGRST_DB_POOL पर निर्भर करता है। ऑराबेस कोड में सत्यापित: एक समर्पित इंस्टेंस (प्रीमियम टियर) डिफ़ॉल्ट रूप से प्रति प्रतिकृति 10 कनेक्शन, या कुल मिलाकर 20 से अधिक 2 प्रतिकृतियां खोलता है। साझा क्लस्टर के समान max_connections बजट पर अधिक किरायेदारों को समायोजित करने के लिए, साझा स्तर स्वेच्छा से इस पूल को 2 प्रति प्रतिकृति, या 4 कनेक्शन प्रति जागृत परियोजना तक कम कर देता है।

क्या कोई आधिकारिक PostgREST बेंचमार्क है?+

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

निष्कर्ष

क्या याद रखना है

अकेले HTTP लोड के तहत PostgREST लगभग कभी नहीं टूटता: इसकी वास्तुकला उसके लिए बहुत सरल है। उत्पादन में जो रुकावट आती है वह इसके चारों ओर होती है: इसकी प्रतिकृतियां कितने कनेक्शन खुली रखती हैं, कुल लागत कितनी होती है। इसमें यह भी शामिल है कि क्या कोई काट-छाँट दृश्यमान रहती है, और माइग्रेशन के बाद विंडो कितने समय तक चलती है।

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