മൾട്ടി-ടെനൻ്റ് SaaS ആർക്കിടെക്ചർ: മൂന്ന് പാറ്റേണുകളും അവ എങ്ങനെ തിരഞ്ഞെടുക്കാമെന്നും

നിങ്ങളുടെ SaaS വളരാൻ തുടങ്ങുന്നത് വരെ അമൂർത്തമായി തോന്നുന്ന ആർക്കിടെക്ചറൽ തീരുമാനങ്ങളിലൊന്നാണ് മൾട്ടി-ടെനൻസി. എന്നാൽ പിന്നീട് അത് എല്ലാറ്റിനെയും സ്പർശിക്കുന്നു — നിങ്ങൾ എങ്ങനെ ഡാറ്റ ക്വറി ചെയ്യുന്നു, നിങ്ങളുടെ ഡാറ്റാബേസ് എങ്ങനെ സ്കെയിൽ ചെയ്യുന്നു, മൈഗ്രേഷനുകൾ എങ്ങനെ നടത്തുന്നു, ഉപഭോക്തൃ ഐസൊലേഷനെക്കുറിച്ച് നിങ്ങൾ എങ്ങനെ ചിന്തിക്കുന്നു എന്നത് വരെ. തുടക്കത്തിൽ തന്നെ ഇത് ശരിയായി ചെയ്താൽ, ആയിരക്കണക്കിന് അക്കൗണ്ടുകളിലേക്ക് നിങ്ങൾക്ക് സുഗമമായി സ്കെയിൽ ചെയ്യാം. തെറ്റിയാലോ, നിങ്ങളുടെ വളർച്ചയുടെ മധ്യത്തിൽ ഉപഭോക്താക്കൾ നോക്കിനിൽക്കെ ഡാറ്റാ ലെയർ മാറ്റിയെഴുതേണ്ടി വരും.

ഇന്ന്, 9 ജൂലൈ 2026-ൽ, മൾട്ടി-ടെനൻ്റ് SaaS ഒരു അസാധാരണ കാര്യമല്ല, മറിച്ച് അതൊരു മാനദണ്ഡമാണ്. നിങ്ങൾ ടീമുകൾക്കായി ഒരു ടൂൾ നിർമ്മിക്കുകയാണെങ്കിലും, എൻ്റർപ്രൈസുകൾക്ക് വിൽക്കുകയാണെങ്കിലും, അല്ലെങ്കിൽ ഉപയോഗാധിഷ്ഠിത വിലനിർണ്ണയം വാഗ്ദാനം ചെയ്യുകയാണെങ്കിലും, നിങ്ങൾ ഈ തീരുമാനം എടുക്കേണ്ടതുണ്ട്. നല്ല വാർത്ത: മിക്ക ഉൽപ്പന്നങ്ങൾക്കും ശരിയായ ഉത്തരം ഇൻ്റർനെറ്റ് പറയുന്നതിനേക്കാൾ വളരെ ലളിതമാണ്.

മൂന്ന് കാനോനിക്കൽ പാറ്റേണുകൾ

ഒരു SaaS ബാക്കെൻഡിൽ ടെനൻ്റുകളെ ഐസൊലേറ്റ് ചെയ്യാൻ നന്നായി സ്ഥാപിക്കപ്പെട്ട മൂന്ന് രീതികളുണ്ട്, അവ പ്രവർത്തനച്ചെലവിനെതിരെ ഐസൊലേഷൻ ട്രേഡ് ചെയ്യുന്നു.

റോ-ലെവൽ ടെനൻസി (പങ്കിട്ട സ്കീമ)

എല്ലാ ടേബിളുകൾക്കും ഒരു tenant_id കോളം ഉണ്ടായിരിക്കും. ഓരോ ക്വറിയും അത് ഫിൽട്ടർ ചെയ്യുന്നു. ഒരു ഡാറ്റാബേസ്, ഒരു സ്കീമ, എല്ലാ ടെനൻ്റുകളും ഒരുമിച്ച്. ഇത് മനസ്സിലാക്കാൻ ഏറ്റവും ലളിതമായതും പ്രവർത്തിപ്പിക്കാൻ ഏറ്റവും ചിലവുകുറഞ്ഞതുമായ പാറ്റേണാണ്.

നിങ്ങൾ ഒരു പ്രോജക്റ്റ്-മാനേജ്മെൻ്റ് ടൂൾ നിർമ്മിക്കുകയാണെന്ന് സങ്കൽപ്പിക്കുക. നിങ്ങളുടെ tasks ടേബിൾ പ്രത്യേക സ്റ്റോറേജുകളായി വിഭജിക്കപ്പെടുന്നില്ല — പകരം, ഓരോ റോയിലും അതിൻ്റെ ഉടമസ്ഥനായ ടെനൻ്റിൻ്റെ ഐഡി ഉണ്ടായിരിക്കും. ഒരു ഉപയോക്താവ് അവരുടെ ടാസ്ക്കുകൾ ക്വറി ചെയ്യുമ്പോൾ, ആപ്ലിക്കേഷൻ ഒരു WHERE ക്ലോസ് ചേർക്കുന്നു: WHERE tenant_id = current_user.tenant_id.

സ്കീമ-പെർ-ടെനൻ്റ്

പങ്കിട്ട ഡാറ്റാബേസിനുള്ളിൽ ഓരോ ടെനൻ്റിനും അവരുടേതായ ഒരു PostgreSQL സ്കീമ ലഭിക്കുന്നു. ഓരോ സ്കീമയും അതിൻ്റേതായ നെയിംസ്പേസ് ആയതുകൊണ്ട് ഐസൊലേഷൻ ശക്തമായിരിക്കും, എന്നാൽ നിയന്ത്രിക്കേണ്ട ഒബ്ജക്റ്റുകൾ കൂടുതലായിരിക്കും. ഒന്നിലധികം സ്കീമകളിൽ അവ പ്രവർത്തിപ്പിക്കുന്നതിനാൽ മൈഗ്രേഷനുകൾ കൂടുതൽ സങ്കീർണ്ണമാകുന്നു. ഈ പാറ്റേൺ റോ-ലെവലിനും പൂർണ്ണ ഐസൊലേഷനും ഇടയിലാണ് സ്ഥിതിചെയ്യുന്നത്.

ഡാറ്റാബേസ്-പെർ-ടെനൻ്റ്

ഓരോ ടെനൻ്റിനും ഒരു സമർപ്പിത ഡാറ്റാബേസ് അല്ലെങ്കിൽ ഇൻസ്റ്റൻസ് ലഭിക്കുന്നു. പരമാവധി ഐസൊലേഷൻ — ഒരു ടെനൻ്റിൻ്റെ ഡാറ്റ തികച്ചും പ്രത്യേകമായ സ്റ്റോറേജിലാണ് സൂക്ഷിക്കുന്നത്. ഉയർന്ന പ്രവർത്തനഭാരവും — ഓരോ ഉപഭോക്താവിനുമായി പ്രത്യേക ഡാറ്റാബേസ് ഇൻസ്റ്റൻസുകൾ, ബാക്കപ്പുകൾ, അപ്‌ഗ്രേഡുകൾ എന്നിവ നിങ്ങൾ മാനേജ് ചെയ്യേണ്ടതുണ്ട്.

മിക്ക SaaS-നും റോ-ലെവൽ വിജയിക്കുന്നത് എന്തുകൊണ്ട്

ഭൂരിഭാഗം B2B SaaS ഉൽപ്പന്നങ്ങൾക്കും, റോ-ലെവൽ മൾട്ടി-ടെനൻസിയാണ് ശരിയായ ഡിഫോൾട്ട്. ഇത് പ്രവർത്തിപ്പിക്കാൻ ഏറ്റവും ചിലവുകുറഞ്ഞതും, മൈഗ്രേഷനുകൾ നടത്താൻ എളുപ്പമുള്ളതും, സ്ഥാപകർ പ്രതീക്ഷിക്കുന്നതിലും കൂടുതൽ സ്കെയിൽ ചെയ്യുന്നതുമാണ്.

എപ്പോഴും ഉയർന്നുവരുന്ന ചോദ്യം ഇതാണ്: "ബട്ട് വാട്ട് എബൌട്ട് ഐസൊലേഷൻ?" ഇവിടെയാണ് പോസ്റ്റ്‌ഗ്രെസ് (Postgres) ശക്തമായ ഉത്തരം നൽകുന്നത്.

റോ-ലെവൽ സെക്യൂരിറ്റിയും (RLS) പോസ്റ്റ്‌ഗ്രെസും

പോസ്റ്റ്‌ഗ്രെസ് റോ-ലെവൽ സെക്യൂരിറ്റി എന്ന ഒരു ഫീച്ചർ നൽകുന്നു. ഒരു ക്വറിക്ക് സ്വന്തം ടെനൻ്റിൻ്റെ റോകൾ മാത്രമേ കാണാൻ കഴിയൂ എന്ന് ഡാറ്റാബേസിനെത്തന്നെ നിർബന്ധിക്കാൻ RLS അനുവദിക്കുന്നു. നിങ്ങൾ ഒരു പോളിസി ഡാറ്റാബേസിൽ നേരിട്ട് സജ്ജീകരിക്കുന്നു — തകരാറുള്ള ഒരു ക്വറിക്ക് പോലും ടെനൻ്റുകൾക്കിടയിൽ ഡാറ്റ ചോർത്താനാകില്ല.

ഹോസ്റ്റ് ചെയ്ത പോസ്റ്റ്‌ഗ്രെസ് പ്ലാറ്റ്‌ഫോമായ സുപാബേസ് (Supabase), RLS-നെ നേറ്റീവ് മോഡലാക്കുന്നു. നിങ്ങൾ ഒരു പോളിസി നിർവചിക്കുന്നു, ഡാറ്റാബേസ് കേവലം ആപ്ലിക്കേഷൻ ലെയർ മാത്രമല്ല, ഒരു സുരക്ഷാ അതിർത്തിയായും മാറുന്നു.

ഓരോ ടേബിളിലുമുള്ള ഒരു tenant_id കൂടെ അതിൽ തുടങ്ങുന്ന ഒരു ഇൻഡക്സും ചേരുന്നതിലൂടെ ഈ പാറ്റേൺ വലിയ ഉപഭോക്തൃ അടിത്തറയെ സുഗമമായി സേവിക്കുന്നു. ഡാറ്റാബേസാണ് ഇത് നിർബന്ധമാക്കുന്നത്. ഫിൽട്ടർ ചെയ്യാൻ ആപ്ലിക്കേഷൻ ഓർക്കേണ്ടതില്ല.

RLS-ൽ ശ്രദ്ധിക്കേണ്ട ഒരു പ്രധാന കാര്യം

അനുഭവത്തിൽ നിന്നുള്ള ഒരു പ്രധാന കാര്യം: ഓരോ റോയ്ക്കും പകരമായി ഓരോ ക്വറിക്കും ഒരിക്കൽ പ്രവർത്തിക്കുന്ന രീതിയിൽ ഹെൽപ്പർ ഫംഗ്ഷനുകൾ ഉപയോഗിച്ച് RLS പോളിസികൾ എഴുതുക. ഓരോ റോയ്ക്കും ലുക്ക്അപ്പ് വീണ്ടും വിലയിരുത്തുന്ന ഒരു പോളിസി ടേബിളുകൾ വലുതാകുമ്പോൾ വേഗതയേറിയ എൻഡ്‌പോയിൻ്റുകളെ നിശബ്ദമായി മെല്ലെയാക്കും. ക്വറി പ്ലാനർ അതിനെ ഒരു init-plan ആയി പ്രവർത്തിപ്പിക്കുന്നതിനായി ചെക്ക് റാപ്പ് ചെയ്യുക എന്നതാണ് പരിഹാരം — ഇത് ഓരോ റോയ്ക്കും പകരം തുടക്കത്തിൽ ഒരു തവണ മാത്രം പരിശോധിക്കുന്നു.

കൂടുതൽ ശക്തമായ ഐസൊലേഷനിലേക്ക് എപ്പോൾ മാറണം

മിക്കവർക്കും റോ-ലെവൽ മതിയാകും. എന്നാൽ ചില ഉപഭോക്താക്കൾക്ക് കൂടുതൽ ആവശ്യമുണ്ട്.

തിടുക്കത്തിലല്ലാതെ ബോധപൂർവ്വം മാറുക:

• നിയമപരമായ അല്ലെങ്കിൽ കരാർ പ്രകാരമുള്ള ഐസൊലേഷൻ — ഒരു ഉപഭോക്താവിന് അവരുടെ ഡാറ്റ ഭൗതികമായി വേർതിരിച്ച ഡാറ്റാബേസിൽ ആവശ്യമാണ്. ഒരുപക്ഷേ അവർ ഒരു നിയന്ത്രിത വ്യവസായത്തിലാകാം, അല്ലെങ്കിൽ ഇത് ആവശ്യപ്പെടുന്ന ഒരു കരാർ വ്യവസ്ഥ അവർക്കുണ്ടാകാം.
• നോയ്‌സി-നെയ്‌ബർ റിസ്ക് — ഒരു വൻകിട ഉപഭോക്താവിൻ്റെ വർക്ക്ലോഡ് ബാക്കിയെല്ലാവരുടെയും പ്രകടനത്തെ ബാധിക്കുന്നു. പ്രത്യേക ഇൻഫ്രാസ്ട്രക്ചർ ഇതിന് പരിഹാരമാകുന്നു.
• പെർ-ടെനൻ്റ് കസ്റ്റമൈസേഷൻ — ഡാറ്റ മാത്രമല്ല, സ്കീമകളും യഥാർത്ഥത്തിൽ വ്യത്യാസപ്പെട്ടിരിക്കുന്നു. വ്യത്യസ്ത ഉപഭോക്താക്കൾക്കായി അടിസ്ഥാനപരമായി വ്യത്യസ്ത ഘടനകളാണ് നിങ്ങൾ സൂക്ഷിക്കുന്നത്.

എന്നിരുന്നാലും, ഒരു ഹൈബ്രിഡ് രീതി നന്നായി പ്രവർത്തിക്കുന്നു: മിക്ക ടെനൻ്റുകളെയും റോ-ലെവലിൽ നിലനിർത്തുക, ഏറ്റവും വലിയ അല്ലെങ്കിൽ ഏറ്റവും സെൻസിറ്റീവ് അക്കൗണ്ടുകളെ മാത്രം ഡെഡിക്കേറ്റഡ് ഡാറ്റാബേസുകളിലേക്ക് മാറ്റുക.

പ്രാധാന്യമർഹിക്കുന്ന ഡിസൈൻ തത്വങ്ങൾ

നിങ്ങൾ എന്ത് തിരഞ്ഞെടുത്താലും, മൾട്ടി-ടെനൻസി തുടക്കത്തിൽ തന്നെ ഉൾപ്പെടുത്തുക. പിന്നീട് അത് കൂട്ടിച്ചേർക്കരുത്.

tenant_id ആവശ്യമുള്ളിടത്തെല്ലാം ഉൾപ്പെടുത്തുക

ചേർക്കുക tenant_id എല്ലാ ഡൊമെയ്ൻ ടേബിളിലേക്കും ഇത് ചേർക്കുകയും നിങ്ങളുടെ കോമ്പോസിറ്റ് ഇൻഡക്സുകൾ ഇതുകൊണ്ട് തുടങ്ങുകയും ചെയ്യുക. ഇത് ക്വറികളെ വേഗത്തിലാക്കുകയും നിങ്ങളുടെ ഡാറ്റ ടെനൻ്റ് അടിസ്ഥാനത്തിൽ സ്വാഭാവികമായി ക്രമീകരിച്ചു വെക്കുകയും ചെയ്യുന്നു.

ടെനൻ്റ് ഐഡൻ്റിറ്റിക്കായി ഒരിക്കലും ക്ലയൻ്റിനെ വിശ്വസിക്കരുത്

ഒരു റിക്വസ്റ്റ് പാരാമീറ്ററിൽ നിന്നോ കുക്കിയിൽ നിന്നോ അല്ലാതെ, എപ്പോഴും ഓതൻ്റിക്കേറ്റഡ് സെഷനിൽ നിന്ന് ടെനൻ്റിനെ കണ്ടെത്തുക. "നിങ്ങൾ ഏത് ടെനൻ്റാണ്?" എന്ന് നിങ്ങൾ ക്ലയൻ്റിനോട് ചോദിച്ചാൽ, തകരാറുള്ളതോ ദുരുദ്ദേശ്യമുള്ളതോ ആയ ക്ലയൻ്റിന് കള്ളം പറയാൻ കഴിയും.

ഡാറ്റാബേസ് ലെയറിൽ ഐസൊലേഷൻ നിർബന്ധമാക്കുക

അതിൻ്റെ WHERE ക്ലോസ് ഓർക്കാൻ ആപ്ലിക്കേഷനെ മാത്രം വിശ്വസിക്കരുത്. ഡാറ്റാ ചോർച്ച അസാധ്യമാക്കാൻ ഡാറ്റാബേസ് കൺസ്ട്രെയിൻ്റുകളും RLS-ഉം ഉപയോഗിക്കുക. ഒരു ഡെവലപ്പർ എവിടെയെങ്കിലും ഒരു ഫിൽട്ടർ മറന്നുപോയാലും, ഡാറ്റാബേസ് തന്നെ തെറ്റ് തടയുന്നു.

ടെനൻ്റ് പ്രൊവിഷനിംഗ് ഒരു ടെസ്റ്റ് ചെയ്ത കോഡ് പാത്ത് ആക്കുക

നിങ്ങൾ ഒരു പുതിയ ടെനൻ്റിനെ ചേർക്കുമ്പോൾ, കൃത്യമായി ടെസ്റ്റ് ചെയ്ത ഒരു പ്രക്രിയയിലൂടെ കടന്നുപോകുക. കോഡ്ബേസിൻ്റെ വിവിധ ഭാഗങ്ങൾ വ്യത്യസ്ത രീതികളിൽ ടെനൻ്റുകളെ സൃഷ്ടിക്കാൻ അനുവദിക്കരുത്. സ്ഥിരത ബഗുകളെ തടയുന്നു.

ഏറ്റവും വലിയ തെറ്റ്

"തെറ്റായ" മോഡൽ തിരഞ്ഞെടുക്കുന്നതല്ല വലിയ തെറ്റ്. ടെനൻസിയെ അവ്യക്തമായി വിടുകയും കോഡ്ബേസിലുടനീളം ഐസൊലേഷൻ ലോജിക് ചിതറിക്കിടക്കാൻ അനുവദിക്കുന്നതുമാണ്. അവസാനമായി ചില എൻഡ്‌പോയിൻ്റുകളിൽ WHERE ക്ലോസുകളും മറ്റുള്ളവയിൽ SQL ജോയിനുകളും വ്യക്തമായ ഒരു നിയമവുമില്ലാത്ത അവസ്ഥ ഉണ്ടാകും.

മൾട്ടി-ടെനൻസിയെ കേന്ദ്രീകരിക്കുക. ഡാറ്റാബേസിൽ അത് നിർബന്ധമാക്കുക. ഒരു തവണ പോളിസി സജ്ജീകരിച്ച് അവിടെ നിന്ന് വികസിപ്പിക്കുക. പരിണമിക്കാനുള്ള സ്വാതന്ത്ര്യം നിങ്ങൾക്ക് നിലനിർത്താം.

ഉപസംഹാരം

മൾട്ടി-ടെനൻ്റ് ആർക്കിടെക്ചർ ഒരു അടിസ്ഥാന തിരഞ്ഞെടുപ്പാണ്. പോസ്റ്റ്‌ഗ്രെസ് റോ-ലെവൽ സെക്യൂരിറ്റിയുള്ള റോ-ലെവൽ ടെനൻസിയാണ് മിക്ക SaaS-നും ശരിയായ ഡിഫോൾട്ട് — ഇത് വിലകുറഞ്ഞതും സ്കെയിൽ ചെയ്യാവുന്നതുമാണ്, മാത്രമല്ല ഡാറ്റാബേസ് ഐസൊലേഷൻ നിർബന്ധമാക്കുകയും ചെയ്യുന്നു. വ്യക്തമായ കാരണമുണ്ടെങ്കിൽ മാത്രം ശക്തമായ പാറ്റേണുകളിലേക്ക് മാറുക: നിയമന്ത്രണം, പെർഫോമൻസ് ഐസൊലേഷൻ, അല്ലെങ്കിൽ യഥാർത്ഥ സ്കീമ വ്യത്യാസം. ആദ്യ ദിവസം മുതൽ തന്നെ ഇത് ഉൾപ്പെടുത്തി ഡിസൈൻ ചെയ്യുക, നിങ്ങളുടെ തിരഞ്ഞെടുപ്പ് ഡോക്യുമെൻ്റ് ചെയ്യുക, അതോടെ നിങ്ങൾക്ക് സുഗമമായി സ്കെയിൽ ചെയ്യാം.

ഗുണങ്ങൾ

• മിക്ക ഉൽപ്പന്നങ്ങൾക്കും പ്രവർത്തിപ്പിക്കാൻ ഏറ്റവും ചിലവുകുറഞ്ഞതും ലളിതവുമായ രീതിയാണ് റോ-ലെവൽ ടെനൻസി.
• പോസ്റ്റ്‌ഗ്രെസ് റോ-ലെവൽ സെക്യൂരിറ്റി ഐസൊലേഷൻ ലോജിക്കിനെ ഡാറ്റാബേസിലേക്ക് മാറ്റുന്നു, അവിടെ അത് സുതാര്യമായി നിർബന്ധമാക്കപ്പെടുന്നു.
• ഒറ്റ ഡാറ്റാബേസും ഒരു സ്കീമയും മൈഗ്രേഷനുകളും ബാക്കപ്പുകളും ലളിതമാക്കുന്നു.
• ആർക്കിടെക്ചർ മാറ്റാതെ തന്നെ നിങ്ങൾക്ക് പിന്നീട് വ്യക്തിഗത ടെനൻ്റുകളെ ശക്തമായ ഐസൊലേഷനിലേക്ക് അപ്‌ഗ്രേഡ് ചെയ്യാം.
• കൂടാതെ tenant_id + ഇൻഡക്സ്-ലീഡിംഗ് പാറ്റേൺ വലിയ ഉപഭോക്തൃ അടിത്തറയിലേക്ക് സ്കെയിൽ ചെയ്യുന്നു.

ദോഷങ്ങൾ

• ഭൗതിക ഡാറ്റാ വേർതിരിക്കൽ ആവശ്യപ്പെടുന്ന റെഗുലേറ്ററി അല്ലെങ്കിൽ കോൺട്രാക്ച്വൽ ആവശ്യകതകൾക്ക് റോ-ലെവൽ ഐസൊലേഷൻ പര്യാപ്തമല്ല.
• ഒരു നോയ്‌സി ടെനൻ്റിൻ്റെ ഹെവി ക്വറികൾ ഒരേ ഡാറ്റാബേസിലെ മറ്റ് ടെനൻ്റുകളെ ബാധിച്ചേക്കാം.
• RLS പോളിസിയിലെ തെറ്റുകൾ (ഓരോ റോയിലും ലോജിക് വീണ്ടും വിലയിരുത്തുന്നത് പോലെ) നിശബ്ദമായി പ്രകടനത്തെ തളർത്താം.
• പിന്നീട് റോ-ലെവലിൽ നിന്ന് സ്കീമ-പെർ-ടെനൻ്റ് അല്ലെങ്കിൽ ഡാറ്റാബേസ്-പെർ-ടെനൻ്റ് എന്നതിലേക്ക് മാറുന്നത് സങ്കീർണ്ണവും അപകടസാധ്യതയുള്ളതുമാണ്.
• എപ്പോഴും ടെനൻ്റ് ഫിൽട്ടറുകൾ ഉൾപ്പെടുത്താൻ ഡെവലപ്പർമാർ സ്വയം അച്ചടക്കം പാലിക്കണം — ഡാറ്റാബേസ് സഹായിക്കുന്നു, എങ്കിലും ആപ്ലിക്കേഷൻ ബഗുകൾ സാധ്യമാണ്.

മുന്നറിയിപ്പ്

ഈ ലേഖനം വിദ്യാഭ്യാസപരവും പൊതുവായ മികച്ച രീതികളെ അടിസ്ഥാനമാക്കിയുള്ളതുമാണ്. ഇതിലെ വിവരങ്ങൾ ഒരു ബ്ലോഗ് പോസ്റ്റിൽ നിന്നുള്ളതാണ്; ആർക്കിടെക്ചറൽ തീരുമാനങ്ങൾ എടുക്കുന്നതിന് മുമ്പ് അവകാശവാദങ്ങൾ ഒറിജിനൽ പബ്ലിക്കേഷനും നിങ്ങളുടെ സ്വന്തം ആവശ്യകതകൾക്കും എതിരായി പരിശോധിക്കണം. റെഗുലേറ്ററി, കംപ്ലയൻസ് ആവശ്യകതകൾ വ്യവസായത്തിനും അധികാരപരിധിക്കും അനുസരിച്ച് വ്യത്യാസപ്പെടുന്നു — നിങ്ങളുടെ നിർദ്ദിഷ്ട ഉപയോഗത്തിനായി നിയമ, സുരക്ഷാ വിദഗ്ധരെ സമീപിക്കുക. നിങ്ങളുടെ സ്വന്തം പരിസ്ഥിതിയിൽ, പ്രത്യേകിച്ച് സ്കെയിലിലെ പെർഫോമൻസ് സ്വഭാവത്തിൽ, RLS പോളിസികൾ നന്നായി പരിശോധിക്കുക. മിഷൻ-ക്രിട്ടിക്കൽ സിസ്റ്റങ്ങൾക്കുള്ള പ്രൊഫഷണൽ ആർക്കിടെക്ചർ അവലോകനത്തിന് ഈ ലേഖനം പകരമാവില്ല.

പതിവായി ചോദിക്കുന്ന ചോദ്യങ്ങൾ

• SaaS-ൽ മൾട്ടി-ടെനൻസി എന്നാൽ എന്താണ്, അത് പ്രധാനമായിരിക്കുന്നത് എന്തുകൊണ്ട്?
• പോസ്റ്റ്‌ഗ്രെസിലെ റോ-ലെവൽ സെക്യൂരിറ്റി ടെനൻ്റുകൾക്കിടയിലെ ഡാറ്റാ ചോർച്ച എങ്ങനെ തടയുന്നു?
• റോ-ലെവൽ ടെനൻസിക്ക് പകരം ഞാൻ എപ്പോൾ സ്കീമ-പെർ-ടെനൻ്റ് ഉപയോഗിക്കണം?
• നോയ്‌സി-നെയ്‌ബർ പ്രശ്നം എന്നാൽ എന്താണ്, അത് SaaS ആർക്കിടെക്ചറിനെ എങ്ങനെ ബാധിക്കുന്നു?
• നിലവിലുള്ള സിംഗിൾ-ടെനൻ്റ് ഡാറ്റാബേസിലേക്ക് ഞാൻ എങ്ങനെ tenant_id ചേർക്കും?
• എനിക്ക് റോ-ലെവൽ വെച്ച് തുടങ്ങുകയും പിന്നീട് ഡാറ്റാബേസ്-പെർ-ടെനൻ്റിലേക്ക് അപ്‌ഗ്രേഡ് ചെയ്യുകയും ചെയ്യാമോ?
• സ്കെയിലിലെ RLS പോളിസികളുടെ പെർഫോമൻസ് പ്രത്യാഘാതങ്ങൾ എന്തൊക്കെയാണ്?
• എൻ്റെ ആപ്ലിക്കേഷനിൽ മൾട്ടി-ടെനൻ്റ് ഐസൊലേഷൻ ഞാൻ എങ്ങനെ പരിശോധിക്കും?

ടാഗുകൾ

#saas #architecture #postgres #scaling #multitenant #database #security #rls