RLS बनाम प्रति प्रोजेक्ट एक समर्पित डेटाबेस

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

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

प्रोविजनर के हालिया समेकन (कोड में "टास्क 12" के रूप में चिह्नित) के बाद से, ऑराबेस में एक सक्रिय पोस्टग्रेज परियोजना बिल्कुल दो आर्किटेक्चर के अंतर्गत आती है - कई परियोजनाओं के बीच वास्तव में साझा किए गए आधार वाले पुराने मॉडल को प्रोविजनिंग पथ से हटा दिया गया है।

pub enum ProjectInstanceKind {
    /// सीएनपीजी क्लस्टर केवल इसी परियोजना (कंपनी स्तर) को समर्पित है।
    FullyDedicated,

    /// परियोजना संगठन के सीएनपीजी क्लस्टर पर डेटाबेस -
    /// समान संगठन की अन्य परियोजनाओं के साथ साझा किया गया,
    /// कभी भी किसी तीसरे पक्ष के संगठन के साथ नहीं।
    SharedClusterDedicated,
}

प्रोजेक्ट स्तर तय करता है कि दोनों में से कौन सा लागू होता है - और यह कोड है जो निर्णय लेता है, डैशबोर्ड में चेक किया गया बॉक्स नहीं:

fn should_provision_dedicated(engine: &str, db_url_encrypted: &Option<String>, plan: &str) -> bool {
    matches!(engine, "postgres" | "postgresql")
        && plan == "enterprise"
        && !non_empty(db_url_encrypted)
}

// shud_route_to_fleet(): कोई भी गैर-कंपनी स्तर (निःशुल्क/समर्थक/टीम)
// आपके अपने संगठन के सीएनपीजी क्लस्टर का मार्ग, कभी भी एक नहीं
// दूसरे से - माइग्रेशन 073, 2 आर्किटेक्चर में समेकन देखें।

दोनों आर्किटेक्चर पर, आधार या क्लस्टर कभी भी दो अलग-अलग संगठनों को होस्ट नहीं करता है - इसलिए सवाल यह नहीं है कि "क्या आपका डेटा अलग है" बल्कि "क्या आपके प्रोजेक्ट ने CloudNativePG की गणना स्वयं की है, या क्या यह इसे उसी संगठन में अन्य परियोजनाओं के साथ साझा करता है।"

दो आर्किटेक्चर का यह समेकन हालिया है: कोड में पहले दो अतिरिक्त पथ थे - एक "साझा मास्टर" जहां कई परियोजनाएं एक ही डेटाबेस में सह-अस्तित्व में थीं, केवल आरेख द्वारा अलग की गईं, और एक postgrest_dedicated_shared_dbसंस्करण। एक समर्पित माइग्रेशन ने उन्हें हटा दिया और projects तालिका की बाधा को केवल दो शेष मानों तक कड़ा कर दिया, ठीक इसलिए क्योंकि साझा स्कीमा मॉडल नीचे वर्णित बग का स्रोत था।

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

इस जमा में एक वास्तविक बग का निशान भी है जो विपरीत जोखिम को दर्शाता है। पुराने साझा स्कीमा मॉडल के तहत (अब वापस ले लिया गया है), provision_postgres_schema ने गलती से प्रत्येक प्रोजेक्ट स्कीमा के लिए GRANT ALL ... TO PUBLIC अधिकार प्रदान कर दिए - PUBLIC ने सदस्यता शर्तों के बिना डेटाबेस में सभी भूमिकाओं पर लागू होते हुए, प्रति प्रोजेक्ट अलग किया गया एक लॉगिन दूसरे के स्कीमा में पढ़ और लिख सकता है। एक सुधारात्मक माइग्रेशन (066) ने इन अधिकारों को मौजूदा अधिकारों से हटा दिया।

23 अगस्त, 2026 का एक पैच उसी दिशा में जाता है: प्रावधानकर्ता द्वारा बिना शर्त रखे गए REVOKE ALL ON SCHEMA public को टोपोलॉजी पर सशर्त बनाया गया था, क्योंकि यह केवल पुराने साझा डेटाबेस मॉडल पर वास्तविक अलगाव प्रदान करता था - दो मौजूदा आर्किटेक्चर पर, इसने SQL डंप के आयात को लाभ के बिना अवरुद्ध कर दिया जो स्पष्ट रूप से public.<table>को संदर्भित करता है।

उपरोक्त में से कोई भी ईपीआईआरबी को बेकार नहीं बनाता है - यह सिर्फ फर्श बदलता है। एक बार आपके प्रोजेक्ट डेटाबेस में, Aurabase बिल्कुल Supabaseद्वारा अपनाए गए PostgREST सम्मेलन को उजागर करता है: तीन SQL फ़ंक्शन जो request.jwt.claimsमें गेटवे द्वारा निर्धारित JWT दावों को पढ़ते हैं।

create function auth.uid() returns uuid
    language sql stable security definer
    set search_path to 'pg_catalog', 'pg_temp'
    as $$
    select nullif(nullif(current_setting('request.jwt.claims', true), '')::json->>'sub', '')::uuid
$$;

इन सहायकों का उपयोग ऑराबेस की वास्तविक नीतियों में ही किया जाता है - न कि केवल आपके लिए प्रलेखित। यहां वह नीति है जो storage_objectsकी सुरक्षा करती है, क्योंकि इसे रिपॉजिटरी में रखा गया है (पढ़ने के लिए कई पंक्तियों में पुन: स्वरूपित किया गया है):

alter table storage_objects enable row level security;

create policy storage_objects_select on storage_objects
  for select using (
    (owner_id = auth.uid())
    or (
      exists (
        select 1 from storage_buckets b
        where (b.name = storage_objects.bucket_name and b.public)
      )
    )
  );

आपके स्वयं के project_<uuid>स्कीमा में, जो आपके एप्लिकेशन तालिकाओं को ले जाता है, ऑराबेस जानबूझकर आपकी ओर से कोई नीति नहीं रखता है - कोड इसे "सुपाबेस मॉडल" के रूप में दस्तावेजित करता है: आपकी तालिकाओं का आरएलएस आपकी ज़िम्मेदारी बनी हुई है, समान कार्यों, समान वाक्यविन्यास के साथ।

पोस्टग्रेज़ मूल रूप से एक भूमिका विशेषता, BYPASSRLSप्रदान करता है, जो सभी नीतियों को अनदेखा करता है। ऑराबेस स्वेच्छा से भूमिकाओं के दो परिवारों पर इसका उपयोग करता है: aura_service_role (सर्वर भूमिका, ब्राउज़र पक्ष पर कभी भी उजागर नहीं) और प्रत्येक प्रोजेक्ट के लिए विशिष्ट प्रशासन भूमिका, जिसका उपयोग ALTER SCHEMA ... OWNER TOजैसे DDL संचालन के दौरान किया जाता है।

create role aura_service_role nologin bypassrls;
-- सर्वर भूमिका: ब्राउज़र पक्ष पर कभी प्रदर्शित नहीं, कभी सदस्य नहीं
-- किसी अन्य प्रोजेक्ट से भूमिकाएँ।

वह भूमिका जो आपके अनुरोधों को पूरा करती है anon/authenticated - tenant_<uuid> - में कोई BYPASSRLSनहीं है: आरएलएस बिना किसी अपवाद के सामान्य रूप से इस पर लागू होता है। एक बोनस के रूप में, प्रत्येक परियोजना के लिए विशिष्ट सिस्टम आरेख (_auth, _storage, _platform) को नीति के बिना एक सक्रिय आरएलएस प्राप्त होता है - इसलिए किसी भी गैर-बायपास भूमिका के लिए डिफ़ॉल्ट रूप से पूर्ण इनकार, एक दिन गलती से एप्लिकेशन पथ तक पहुंचने की स्थिति में गहराई से बचाव।

यह सर्वर भूमिका एक व्यापक स्थिति का हिस्सा है - पूर्वनिर्धारित भूमिकाएँ, कस्टम RBAC, ऑडिट लॉग - सुरक्षा और RBACपृष्ठ पर विस्तृत है।

SharedClusterDedicatedस्तर पर, एक ही संगठन की कई परियोजनाएं एक ही सीएनपीजी क्लस्टर पर सह-अस्तित्व में हैं। भौतिक डेटाबेस पहले से ही परियोजनाओं को एक-दूसरे से अलग करता है, लेकिन PostgreSQL भूमिकाएँ - वे - क्लस्टर के लिए वैश्विक ऑब्जेक्ट हैं, डेटाबेस के लिए नहीं। इसलिए ऑराबेस एक परत जोड़ता है: प्रति प्रोजेक्ट एक अलग PostgreSQL लॉगिन।

pub fn project_authenticator_role(project_id: &str) -> String {
    format!("project_{}_authenticator", project_id.replace('-', '_'))
}

// डिफ़ॉल्ट रूप से सक्रिय (F013_PER_PROJECT_AUTHENTICATOR), निष्क्रिय करने योग्य
// स्पष्ट रूप से एक आपातकालीन पलायन के रूप में।

प्रत्येक प्रोजेक्ट अपने स्वयं के लॉगिन से जुड़ता है, केवल अपनी tenant_<uuid> / tenant_<uuid>_admin भूमिकाओं का सदस्य होता है - कभी भी उसी क्लस्टर में किसी अन्य प्रोजेक्ट का नहीं। डेटाबेस पहले से ही डेटा को अलग कर देता है; यह लॉगिन प्रति प्रोजेक्ट उस पहचान को भी अलग कर देता है जो उससे जुड़ती है, ताकि किसी प्रोजेक्ट पर कोई घटना उसके लॉगिन को किसी अन्य को विरासत में लेने के लिए कोई सदस्यता न दे।

ऑराबेस का चुनाव एक सार्वभौमिक नियम नहीं है - यह एक विशिष्ट मामले के लिए एक समझौता है: ग्राहकों को एक दूसरे से अलग करना, संभावित रूप से विभिन्न अनुपालन आवश्यकताओं के साथ, एक ऐसे मंच पर जिसे वे नियंत्रित नहीं करते हैं। यदि आप अपना स्वयं का SaaS बना रहे हैं, तो आपके लिए भी यही प्रश्न एक अलग पैमाने पर उठता है।

• साझा आधार में tenant_id के साथ आरएलएस - तब प्रासंगिक होता है जब आपके किरायेदार असंख्य होते हैं, व्यक्तिगत रूप से कम हिस्सेदारी वाले होते हैं, और प्रति किरायेदार आधार की लागत अनुपातहीन होगी। बिना किसी अपवाद के, प्रत्येक तालिका पर pg_proveके साथ प्रत्येक नीति का परीक्षण करें।
• समर्पित आधार या आरेख - प्रासंगिक जब भी किसी किरायेदार के पास अपना अनुपालन मुद्दा (स्वास्थ्य, मानव संसाधन, सार्वजनिक क्षेत्र) होता है, एक मात्रा जो प्रदर्शन अलगाव को उचित ठहराती है, या दो विशिष्ट ग्राहकों के बीच रिसाव की लागत अतिरिक्त बुनियादी ढांचे की लागत से असंगत होगी।

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