PostgREST संगतता: इसमें क्या शामिल है, और विकल्प

PostgREST एक स्वायत्त वेब सर्वर है जो मौजूदा PostgreSQL डेटाबेस को सीधे उसके स्कीमा से REST API में बदल देता है। लिखने के लिए कोई अनुप्रयोग परत नहीं: तालिकाएँ, दृश्य और फ़ंक्शन मार्ग बन जाते हैं, और SQL अनुमतियाँ - भूमिकाएँ, RLS नीतियाँ - प्राधिकरण परत बन जाती हैं।

सीधे तौर पर, PostgREST पाँच क्षमताओं को शामिल करता है जो लगभग सभी मूल्यांकनों में सामने आती हैं:

• क्षैतिज फ़िल्टरिंग - लगभग तीस ऑपरेटर (eq, gt, like, ilike, in, is, cs, ov, fts...) सीधे क्वेरी स्ट्रिंग में।
• लंबवत फ़िल्टरिंग और एम्बेडिंग - ?select= कॉलम प्रोजेक्ट करता है और विदेशी कुंजी के माध्यम से संबंधों को एम्बेड करता है, उदाहरण के लिए customer:customers(email)।
• RPC - एक POST /rpc/{fonction} सीधे SQL फ़ंक्शन को कॉल करता है, जो एक समापन बिंदु बन जाता है।
• RLS JWT द्वारा संचालित - PostgREST प्राप्त टोकन (SET LOCAL ROLE) के अनुसार सक्रिय पोस्टग्रेज भूमिका को स्विच करता है, इसलिए आपकी नीतियां एप्लिकेशन पक्ष पर डुप्लिकेट प्राधिकरण तर्क के बिना लागू होती हैं।
• स्व-निर्मित ओपनएपीआई - विनिर्देश हाथ से बनाए रखने के लिए फ़ाइल के बिना, उजागर स्कीमा से निकाला गया है।

curl "https://<gateway>/v1/db/<project_id>/orders \
  ?select=id,total,customer:customers(email) \
  &status=eq.paid \
  &order=created_at.desc" \
  -H "apikey: <votre-cle-api>"

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

RPC उसी तर्क का अनुसरण करती है: आपके डेटाबेस में पहले से लिखा गया एक SQL फ़ंक्शन एक POST समापन बिंदु बन जाता है, जिसके तर्क JSON में पारित हो जाते हैं।

curl -X POST "https://<gateway>/v1/db/<project_id>/rpc/monthly_revenue" \
  -H "apikey: <votre-cle-api>" \
  -H "Content-Type: application/json" \
  -d '{"year": 2026, "month": 8}'

यह सिद्धांत - पोस्टग्रेज स्कीमा एपीआई के सत्य का एकल स्रोत है - जो पोस्टग्रैस्ट को पूर्वानुमानित बनाता है: प्रत्येक व्यवहार परिवर्तन एक एसक्यूएल माइग्रेशन के माध्यम से होता है, कभी भी एक अलग एप्लिकेशन परत के माध्यम से नहीं होता है जो वास्तविक स्कीमा से प्राप्त हो सकता है। प्रोजेक्ट खुला स्रोत है, जिसे GitHubपर विकसित किया गया है, जो किसी विशेष BaaS प्रदाता से स्वतंत्र है।

PostgREST CRUD परत का समाधान करता है। यह शेष एप्लिकेशन बैकएंड का समाधान नहीं करता है। इसे अकेले अपनाने वाली टीमों के बीच व्यवस्थित रूप से चार कमियाँ होती हैं।

• प्रमाणीकरण - कोई JWT जारी करना या एकीकृत उपयोगकर्ता प्रबंधन नहीं। आपको इसे SQL में बनाना होगा या किसी बाहरी सेवा को सौंपना होगा।
• फ़ाइल भंडारण - कोई नहीं। एक S3 बाल्टी या समकक्ष को अलग से जोड़ा जाना बाकी है।
• वास्तविक समय - PostgREST एकबारगी HTTP अनुरोधों का जवाब देता है, यह किसी भी घटना को आगे नहीं बढ़ाता है।
• कनेक्शन पूलर - PostgREST स्वयं Postgres से जुड़ता है, लेकिन किसी भी उन्नत पूलर को एकीकृत नहीं करता है। बड़े पैमाने पर, इसे प्रबंधित करना अपने आप में एक परिचालन निर्णय बन जाता है: क्लासिक लेनदेन मोड में एक पूलर PostgREST स्कीमा पुनः लोडिंग तंत्र के साथ संघर्ष करता है (नीचे देखें कि ऑराबेस इस समझौते को कैसे हल करता है)।

एक व्यावहारिक परिणाम स्पष्ट रूप से कहा जाना चाहिए: प्रमाणीकरण के बिना, आपकी आरएलएस नीतियां एक अज्ञात ग्राहक और आपके डेटा के बीच एकमात्र सुरक्षा सीमा बन जाती हैं। anon भूमिका पर एक खराब लिखित नीति एक अतिरिक्त एप्लिकेशन परत से आगे नहीं बढ़ती है - ऐसा कुछ भी नहीं है।

ऑराबेस पोस्टग्रेज इंजन प्रोजेक्ट पर - डिफ़ॉल्ट इंजन - गेटवे प्रत्येक CRUD अनुरोध को सीधे इस प्रोजेक्ट के लिए समर्पित PostgREST v12.2.8 इंस्टेंस पर रूट करता है, दो प्रतिकृतियां, किरायेदार के पोस्टग्रेज क्लस्टर के साथ सह-स्थित। यह अनुमानित अनुकूलता नहीं है: यह स्वयं PostgREST अपस्ट्रीम बाइनरी है, समान ऑपरेटरों, समान एम्बेडिंग, समान RPC, JWT द्वारा संचालित समान RLS के साथ।

MongoDB इंजन प्रोजेक्ट पर, कहानी अलग है। MongoDB के पास PostgREST के समकक्ष कोई नहीं है: इन अनुरोधों को एक आंतरिक Aurabase सेवा पर रूट किया जाता है, जो समान सम्मेलनों के एक उपसमूह को फिर से लागू करता है - समान ऑपरेटर नाम, एम्बेडिंग के साथ ?select= सिंटैक्स, Prefer और Content-Range हेडर - लेकिन एक दस्तावेज़ इंजन पर, एक रिलेशनल नहीं। इस परत की अपनी सीमाएँ हैं: उत्परिवर्तन द्वारा लौटाए गए प्रतिनिधित्व में अनुरोधित एम्बेडिंग को चुपचाप अनदेखा करने के बजाय स्पष्ट रूप से अस्वीकार कर दिया जाता है, और SQL फ़ंक्शंस के बराबर कोई RPC मार्ग नहीं है।

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

उत्पादन में एक और उपयोगी विवरण: संसाधनों को बचाने के लिए एक निष्क्रिय परियोजना को रोका जा सकता है। स्लीपिंग प्रोजेक्ट पर पहला अनुरोध इसके वेक-अप को ट्रिगर करता है और पुनः प्रयास में देरी के साथ 503 प्राप्त करता है, समर्पित PostgREST उदाहरण के वापस आने का समय - लागत और कोल्ड विलंबता के बीच एक अनुमानित समझौता, कोई छिपी हुई घटना नहीं।

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

नीचे दी गई तालिका तुलना करती है कि प्रत्येक विकल्प मूल रूप से क्या कवर करता है और यह स्पष्ट रूप से आप पर क्या छोड़ता है - प्रत्येक प्रोजेक्ट द्वारा चुने गए आर्किटेक्चर पर मूल्य निर्णय के बिना।

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

GraphQL दृष्टिकोणों - pg_graphql, हसुरा और PostGraphile के बीच विस्तृत तुलना के लिए - Postgres पर GraphQL API को समर्पित हमारा लेख देखें।

चार स्थितियाँ सबसे अधिक बार सामने आती हैं। सही विकल्प मुख्य रूप से इस बात पर निर्भर करता है कि आप स्वयं क्या इकट्ठा करना और बनाए रखना चाहते हैं।

• आप मौजूदा पोस्टग्रेज़ स्कीमा पर केवल एक REST API चाहते हैं, और कुछ नहीं। स्व-होस्ट किया गया PostgREST पर्याप्त है: यह बिल्कुल वही करता है जो यह करता है, और कुछ भी स्थापित करने की आवश्यकता नहीं है।
• आपको अतिरिक्त प्रमाणीकरण, भंडारण और वास्तविक समय की आवश्यकता है, और आप कई सेवाओं को इकट्ठा करने के लिए तैयार हैं। Supabase, या PostgREST आपके स्वयं के एप्लिकेशन स्टैक के साथ, इस आवश्यकता को पूरा करता है।
• आप REST की तुलना में GraphQL को प्राथमिकता देते हैं। हसुरा या पोस्टग्राफाइल इस मैदान को कवर करता है - एक अलग वास्तुशिल्प विकल्प, पोस्टग्रेस्ट का सीधा प्रतिस्थापन नहीं।
• आप कई अलग-अलग सेवाओं को एक साथ जोड़े बिना एक संपूर्ण पोस्टग्रेज बैकएंड चाहते हैं। यह वह कोण है जो हमारे एकीकृत रस्ट आर्किटेक्चर दस्तावेज़: CRUD परत के लिए वास्तविक पोस्टग्रेस्ट, मूल रूप से प्रमाणीकरण, भंडारण, वास्तविक समय और किनारे कार्यों से घिरा हुआ है।