PostgREST बनाम Hasura बनाम एक कस्टम एपीआई

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

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

This article extends two comparisons already published on this blog: our review of PostgREST compatibility and its alternatives and our comparison dedicated to GraphQL layers on Postgres. Here the angle changes: a decision grid between three ways to build an API layer, with Hasura treated for its permissions and business extension points rather than its GraphQL syntax, and a hand-written API as an option in its own right, not a simple "else" line at the bottom of the table.

अनिवार्य है

PostgREST, Postgres स्कीमा से एक REST API स्वतः उत्पन्न करता है - कोई मनमाना व्यावसायिक तर्क संभव नहीं है, RLS ही एकमात्र सुरक्षा सीमा बनी हुई है।
हसुरा अपने ग्राफक्यूएल इंजन के शीर्ष पर भूमिका और तालिका, व्यवसाय वेबहुक, इवेंट ट्रिगर्स और रीस्टिफाइड एंडपॉइंट्स को जोड़ने के लिए अपनी स्वयं की अनुमति प्रणाली जोड़ता है।
एक कस्टम एपीआई (Node.js, Express, Fastify...) व्यवसाय तर्क, सत्यापन और प्रमाणीकरण पर पूर्ण नियंत्रण देता है - सब कुछ लिखने, परीक्षण करने और बनाए रखने की कीमत पर।
ऑराबेस पर, PostgREST परत एक वास्तविक उदाहरण है; सीआरयूडी से परे व्यावसायिक तर्क आरपीसी में प्रदर्शित एसक्यूएल फ़ंक्शंस या एज फ़ंक्शंस के माध्यम से जाता है, होस्ट करने के लिए एक अलग नोड सर्वर के माध्यम से नहीं।
तीन दृष्टिकोण आवश्यक रूप से परस्पर अनन्य नहीं हैं: सीआरयूडी के लिए पोस्टग्रेस्ट और संवेदनशील संचालन के लिए एक कस्टम एपीआई का संयोजन उत्पादन में एक सामान्य पैटर्न है।

सिंहावलोकन

वास्तविक विकल्प: व्यावसायिक तर्क कौन लिखता है, और कहाँ

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

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

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

अनुस्मारक

PostgREST: एपीआई स्कीमा के प्रत्यक्ष प्रतिबिंब के रूप में

PostgREST आपके Postgres स्कीमा को REST API में बदल देता है - फ़िल्टर, रिलेशनशिप एम्बेडिंग, RPC, JWT द्वारा संचालित RLS - जिसमें लिखने के लिए कोई बैकएंड नहीं है। हमने अपने लेख में इसकी वास्तविक संगतता और इसके विकल्पों पर इस दायरे का गहराई से विवरण दिया है; इस तुलना के लिए जो बात मायने रखती है वह यह है कि PostgREST कहां रुकता है।

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

सीधे तौर पर, किसी तृतीय-पक्ष भुगतान सेवा को कॉल करना, पुष्टिकरण ईमेल भेजना, या सीधे PostgREST अनुरोध से जावास्क्रिप्ट में स्कोर की गणना करना असंभव है। यह तर्क या तो SQL (pl/pgsql फ़ंक्शन) में रहना चाहिए, या बाहर ट्रिगर किया जाना चाहिए - एक ट्रिगर जो NOTIFYईवेंट प्रकाशित करता है, जिसे बाहरी सेवा द्वारा सुना जाता है जो अब PostgREST नहीं है।

तुलना

हसूरा: अनुमतियाँ घोषित, वेबहुक द्वारा व्यावसायिक तर्क तैयार किया गया

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

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

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

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

दोहराने लायक बात

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

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

तुलना

कस्टम एपीआई (नोड.जेएस, एक्सप्रेस, फास्टिफ़ाई): सब कुछ कोड करें, सब कुछ नियंत्रित करें

परिभाषा के अनुसार, हस्तलिखित एपीआई की कोई सीमा नहीं है: कोई भी व्यावसायिक तर्क, किसी भी भाषा में, किसी भी निर्भरता के साथ। यह उन तीन विकल्पों में से एकमात्र विकल्प है जहां आपके लिए कुछ भी उत्पन्न नहीं होता है - प्रत्येक मार्ग, प्रत्येक सत्यापन, डेटाबेस से प्रत्येक कनेक्शन वह कोड है जो आपके पास है और जिसे आपको बनाए रखना होगा।

routes/orders.js (Express, extrait)javascript

// फ़िल्टर, सॉर्टिंग और रिलेशनशिप एम्बेडिंग हाथ से लिखी जाती है,
// अकेले इस मार्ग के लिए - प्रत्येक एपीआई संसाधन के लिए दोहराएं
router.get('/orders', async (req, res) => {
  const { status } = req.query
  const result = await db.query(
    `SELECT o.id, o.total, c.email AS customer_email
     FROM orders o JOIN customers c ON c.id = o.customer_id
     WHERE o.status = $1 ORDER BY o.created_at DESC`,
    [status]
  );
  res.json(result.rows)
});

यह मॉडल मैन्युअल कार्य के बदले में क्या प्रदान करता है: त्रुटियों पर पूर्ण नियंत्रण और HTTP कोड लौटाए, क्लासिक टेस्टेबिलिटी (हैंडलर, घोषणात्मक कॉन्फ़िगरेशन नहीं), और उस टीम के लिए सीखने के लिए कोई नया डीएसएल नहीं जो पहले से ही अपनी भाषा में महारत हासिल करता है।

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

कच्चे प्रदर्शन पर, प्रश्न "क्या Node.js रस्ट से धीमा है" अपने आप में एक विषय है - रस्ट बनाम Node.js विलंबता पर हमारा लेख इसे विस्तार से कवर करता है, हमारे बेंचमार्क पद्धति पृष्ठपर अपस्ट्रीम घोषित कार्यप्रणाली के साथ। एक कस्टम एपीआई का प्रदर्शन प्रोफ़ाइल आपके द्वारा पहले से उपयोग की जाने वाली किसी भी HTTP सेवा के समान होता है, निर्माण के हिसाब से न तो बेहतर और न ही बदतर। सटीक रूप से जानने के लिए कि PostgREST कहां संतृप्त होता है और किस बिंदु पर एक कस्टम परत आवश्यक हो जाती है, उत्पादन में PostgREST की वास्तविक सीमाएं पर हमारा लेख देखें।

फ़ैसला

तुलना तालिका: तीन विकल्प एक साथ

वास्तुकला से परे, चुनते समय चार मानदंड अक्सर सामने आते हैं: कार्यान्वयन की गति, वास्तविक व्यापार लचीलापन, दीर्घकालिक तकनीकी ऋण, और विशिष्ट उपयोग का मामला जहां प्रत्येक विकल्प सबसे आरामदायक होता है।

प्रारंभिक सेटअप	मिनट - स्कीमा पहले से मौजूद है	घंटे - आधार कनेक्ट करें, अनुमतियाँ कॉन्फ़िगर करें	दिन से सप्ताह तक - प्रत्येक मार्ग लिखें
व्यावसायिक लचीलापन	एसक्यूएल तक सीमित (आरपीसी, ट्रिगर्स)	क्रियाओं/इवेंट ट्रिगर्स के माध्यम से अच्छा है, लेकिन बाहरी वेबहुक के माध्यम से जाता है	संपूर्ण, सीधा
अवधि तकनीकी ऋण	कमजोर - आरेख सत्य का एकमात्र स्रोत बना हुआ है	मध्यम - स्कीमा के अतिरिक्त बनाए रखने के लिए हसुरा मेटाडेटा	यदि टीम अनुशासन के बिना बढ़ती है तो उच्च (परीक्षण, दस्तावेज़ीकरण, समीक्षा)
विशिष्ट उपयोग का मामला	एक स्थिर स्कीमा पर डायरेक्ट सीआरयूडी, एसक्यूएल में टीम आरामदायक	कई डेटा स्रोतों, या एआई एजेंट-उन्मुख तर्क को फ़ेडरेट करें	जटिल व्यावसायिक तर्क, अनेक तृतीय-पक्ष एकीकरण
	पोस्टग्रेस्ट	हसूरा	कस्टम एपीआई

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

ऑराबेस परियोजना पर व्यावसायिक तर्क कहाँ जाता है?

ऑराबेस पोस्टग्रेज इंजन प्रोजेक्ट पर, CRUD परत पहले से ही एक वास्तविक PostgREST उदाहरण द्वारा कवर की गई है, न कि अनुमानित पुन: कार्यान्वयन द्वारा। इस तुलना के लिए यह प्रश्न खुला रहता है: सीआरयूडी से आगे क्या लिखा जाए, इसे कहां लिखा जाए?

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

आरपीसी कॉल - एसक्यूएल में व्यावसायिक तर्कbash

curl -X POST "https://<gateway>/v1/db/<project_id>/rpc/apply_discount" \
  -H "apikey: <votre-cle-api>" \
  -H "Content-Type: application/json" \
  -d '{"order_id": 42, "code": "WELCOME10"}'

दूसरा तरीका: एज फ़ंक्शंस, SQL डोमेन से परे जाने वाली हर चीज़ के लिए - भुगतान एपीआई को कॉल करना, ईमेल भेजना, एम्बेडिंग की गणना करना। ऑराबेस में दो रास्ते जाते हैं: स्टूडियो संपादक, जो बिल्कुल सुपाबेस की तरह डेनो (टाइपस्क्रिप्ट) कोड चलाता है, और aura functions deployCLI, जिसका उद्देश्य रस्ट में लिखे गए और WASM में संकलित कार्यों के लिए एक अलग पथ है - हमारे एकीकृत रस्ट आर्किटेक्चरमें विस्तृत है। इस आलेख में शुद्ध "कस्टम एपीआई" विकल्प के विपरीत, किसी भी पथ को एक अलग नोड सर्वर होस्ट करने की आवश्यकता नहीं है, जहां वह सर्वर पूरी तरह से आपकी ज़िम्मेदारी है।

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

फ़ैसला

अपने संदर्भ के अनुसार कैसे चयन करें

चार स्थितियाँ सबसे अधिक बार सामने आती हैं। सही विकल्प अधिकतर इस बात पर निर्भर करता है कि आपके व्यावसायिक तर्क की क्या आवश्यकता है, न कि किसी उपकरण की लोकप्रियता पर।

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

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

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

क्या PostgREST कस्टम Node.js API को प्रतिस्थापित कर सकता है?+

सीआरयूडी परत के लिए, अक्सर हाँ। किसी भी व्यावसायिक तर्क के लिए जो SQL फ़ंक्शन ठीक से व्यक्त कर सकता है उससे आगे जाता है, नहीं: कस्टम एपीआई या हसुरा क्रियाओं के विपरीत, PostgREST में मनमाने व्यावसायिक तर्क की कोई धारणा नहीं है, जो इस तर्क को एप्लिकेशन कोड को सौंपता है।

क्या हसुरा खुला स्रोत है?+

हसुरा ग्राफक्यूएल इंजन को ओपन सोर्स के रूप में जारी किया गया है। प्रॉम्प्टक्यूएल, एआई एजेंटों के लिए डिज़ाइन की गई परत जिस पर हसुरा ने जून 2025 से अपने संचार को फिर से केंद्रित किया है, इस इंजन से एक अलग उत्पाद है।

क्या हम PostgREST और एक कस्टम API को एक ही प्रोजेक्ट पर जोड़ सकते हैं?+

हाँ, और यह एक सामान्य पैटर्न है। PostgREST क्लाइंट के सामने आने वाले मानक CRUD को कवर करता है, जबकि एक अलग API या फ़ंक्शन संवेदनशील संचालन (भुगतान, ईमेल भेजना, मल्टी-स्टेप लॉजिक) को संभालता है जो फिर उसी Postgres डेटाबेस को कॉल करता है।

क्या ऑराबेस हसुरा एकीकरण की पेशकश करता है?+

नहीं, ऑराबेस मूल रूप से REST के लिए PostgREST को एकीकृत करता है और वैकल्पिक रूप से GraphQL के लिए pg_graphql को एकीकृत करता है, हसुरा को नहीं। तीनों दृष्टिकोण कागज पर तुलनीय हैं, लेकिन मंच पर विनिमेय नहीं हैं।