பல வாடகைதாரர் SaaS கட்டமைப்பு: மூன்று வடிவங்கள் மற்றும் எப்படி தேர்ந்தெடுப்பது

பல-வாடகைதாரர் அமைப்பு என்பது உங்கள் SaaS வளரத் தொடங்கும் வரை சுருக்கமாகத் தோன்றும் ஒரு கட்டமைப்பு முடிவுகளில் ஒன்றாகும். பின்பு அது எல்லாவற்றையும் தொடுகிறது — நீங்கள் எப்படி தரவை வினவுகிறீர்கள், உங்கள் தரவுத்தளத்தை எப்படி அளவிடுகிறீர்கள், இடம்பெயர்வுகளை (migrations) எப்படி இயக்குகிறீர்கள், மேலும் வாடிக்கையாளர் தனிமைப்படுத்தல் பற்றி நீங்கள் எப்படி சிந்திக்கிறீர்கள் என்பது வரை. ஆரம்பத்திலேயே அதைச் சரியாகச் செய்யுங்கள், மேலும் நீங்கள் ஆயிரக்கணக்கான கணக்குகளுக்கு சீராக அளவிடலாம். அதைத் தவறாகச் செய்தால், உங்கள் வாடிக்கையாளர்கள் பார்த்துக் கொண்டிருக்கும்போதே வளர்ச்சியின் பாதியில் உங்கள் தரவு அடுக்கை (data layer) மீண்டும் எழுதுவீர்கள்.

இன்று, 9 ஜூலை 2026, பல-வாடகைதாரர் SaaS என்பது விதிவிலக்கல்ல, இதுவே வழக்கம். நீங்கள் அணிகளுக்கான ஒரு கருவியை உருவாக்கினாலும், நிறுவனங்களுக்கு விற்றாலும் அல்லது பயன்பாடு-அடிப்படையிலான விலை நிர்ணயத்தை வழங்கினாலும், நீங்கள் இந்த முடிவை எடுக்கிறீர்கள். நல்ல செய்தி: பெரும்பாலான தயாரிப்புகளுக்கு, இணையம் பரிந்துரைப்பதை விட சரியான பதில் எளிமையானது.

மூன்று அங்கீகரிக்கப்பட்ட வடிவங்கள்

SaaS பின்தளத்தில் வாடகைதாரர்களைத் தனிமைப்படுத்த மூன்று நன்கு-நிறுவப்பட்ட வழிகள் உள்ளன, மேலும் அவை தனிமைப்படுத்துதலை செயல்பாட்டுச் செலவுக்கு எதிராக பரிமாறிக்கொள்கின்றன.

வரிசை-நிலை வாடகைதாரர் (பகிரப்பட்ட ஸ்கீமா)

ஒவ்வொரு அட்டவணையிலும் ஒரு tenant_id நெடுவரிசை (column) உள்ளது. ஒவ்வொரு வினவலும் அதில் வடிகட்டுகிறது. ஒரு தரவுத்தளம், ஒரு ஸ்கீமா, அனைத்து வாடகைதாரர்களும் ஒன்றாக. இது புரிந்துகொள்ள எளிமையான வடிவம் மற்றும் செயல்பட மிகவும் மலிவானது.

நீங்கள் ஒரு திட்ட-மேலாண்மைக் கருவியை உருவாக்குகிறீர்கள் என்று கற்பனை செய்து பாருங்கள். உங்கள் tasks அட்டவணை தனி சேமிப்பகமாகப் பிரிக்கப்படுவதில்லை — அதற்குப் பதிலாக, ஒவ்வொரு வரிசையும் அதை வைத்திருக்கும் வாடகைதாரரின் ID ஐக் கொண்டுள்ளது. ஒரு பயனர் தங்கள் பணிகளை வினவும்போது, பயன்பாடு ஒரு WHERE விதியைச் சேர்க்கிறது: WHERE tenant_id = current_user.tenant_id.

ஒவ்வொரு-வாடகைதாரருக்கும்-ஸ்கீமா

பகிரப்பட்ட தரவுத்தளத்திற்குள் ஒவ்வொரு வாடகைதாரருக்கும் அதன் சொந்த PostgreSQL ஸ்கீமா கிடைக்கிறது. ஒவ்வொரு ஸ்கீமாவும் அதன் சொந்த பெயர்வெளி (namespace) என்பதால் வலுவான தனிமைப்படுத்தல், ஆனால் நிர்வகிக்க அதிக பொருள்கள். இடம்பெயர்வுகள் (Migrations) மிகவும் சிக்கலானதாகின்றன — நீங்கள் அவற்றை பல ஸ்கீமாக்களில் இயக்குகிறீர்கள். இந்த வடிவம் வரிசை-நிலை மற்றும் முழுமையான தனிமைப்படுத்தல் ஆகியவற்றுக்கு இடையே அமர்ந்திருக்கிறது.

ஒவ்வொரு-வாடகைதாரருக்கும்-தரவுத்தளம்

ஒவ்வொரு வாடகைதாரருக்கும் ஒரு பிரத்யேக தரவுத்தளம் அல்லது நிகழ்வு (instance) கிடைக்கிறது. அதிகபட்ச தனிமைப்படுத்தல் — ஒரு வாடகைதாரரின் தரவு முற்றிலும் தனித்தனி சேமிப்பகத்தில் வாழ்கிறது. அதிகபட்ச செயல்பாட்டு எடையும் கூட — ஒவ்வொரு வாடிக்கையாளருக்கும் தனித்தனி தரவுத்தள நிகழ்வுகள், காப்புப்பிரதிகள் (backups) மற்றும் மேம்படுத்தல்களை நீங்கள் நிர்வகிக்கிறீர்கள்.

பெரும்பாலான SaaS-க்கு வரிசை-நிலை ஏன் வெற்றி பெறுகிறது

பெரும்பான்மையான B2B SaaS தயாரிப்புகளுக்கு, வரிசை-நிலை பல-வாடகைதாரர் அமைப்பே சரியான முன்னிருப்பு ஆகும். இது செயல்பட மலிவானது, இடம்பெயர்வுகளை இயக்க எளிதானது, மற்றும் நிறுவனர்கள் எதிர்பார்ப்பதை விட இது மேலும் அளவிடப்படுகிறது.

ஆட்சேபனை எப்போதும் இதுவாகவே இருக்கும்: "ஆனால் தனிமைப்படுத்தல் பற்றி என்ன?" இங்குதான் Postgres ஒரு வலுவான பதிலைக் கொண்டுள்ளது.

வரிசை-நிலை பாதுகாப்பு (RLS) மற்றும் Postgres

Postgres வரிசை-நிலை பாதுகாப்பு (Row-Level Security) என்ற அம்சத்தை வழங்குகிறது. ஒரு வினவல் அதன் சொந்த வாடகைதாரரின் வரிசைகளை மட்டுமே காண முடியும் என்பதை தரவுத்தளமே செயல்படுத்த RLS அனுமதிக்கிறது. நீங்கள் ஒரு கொள்கையை ஒரு முறை அமைப்பீர்கள் — நேரடியாக தரவுத்தளத்தில் — மற்றும் ஒரு பிழையான வினவல் கூட வாடகைதாரர்கள் முழுவதும் தரவைக் கசியவிட முடியாது.

Supabase, ஒரு வழங்கப்பட்ட (hosted) Postgres தளம், RLS ஐ சொந்த மாதிரியாக ஆக்குகிறது. நீங்கள் ஒரு கொள்கையை வரையறுக்கிறீர்கள், மேலும் தரவுத்தளம் பயன்பாட்டு அடுக்கு மட்டுமல்லாமல் ஒரு பாதுகாப்பு எல்லையாகிறது.

இதனுடன் இணைந்து ஒரு tenant_id ஒவ்வொரு அட்டவணையிலும் மற்றும் அதனுடன் வழிநடத்தும் ஒரு குறியீடும் (index), இந்த வடிவம் வசதியாக பெரிய வாடிக்கையாளர் தளங்களுக்குச் சேவை செய்கிறது. தரவுத்தளம் செயல்படுத்துதலைச் செய்கிறது. வடிகட்ட பயன்பாடு நினைவில் கொள்ள வேண்டியதில்லை.

RLS பற்றிய ஒரு உண்மையான எச்சரிக்கை

அனுபவத்தில் இருந்து ஒரு முக்கியமான விவரம்: RLS கொள்கைகளை எழுதுங்கள், அதனால் உதவி செயல்பாடுகள் ஒவ்வொரு வினவலுக்கும் ஒரு முறை இயங்கும், ஒவ்வொரு வரிசைக்கும் ஒரு முறை அல்ல. ஒவ்வொரு வரிசைக்கும் ஒரு தேடலை மீண்டும் மதிப்பிடும் கொள்கை, அட்டவணைகள் வளரும்போது வேகமாக செயல்படும் இறுதிப்புள்ளிகளை (endpoints) மெதுவாக மாற்றும். தீர்வு என்னவென்றால், சோதனையைச் சுற்றுவதுதான் (wrap the check), இதனால் வினவல் திட்டமிடுபவர் அதை ஒரு init-plan ஆக இயக்குவார் — ஒவ்வொரு வரிசைக்கும் அல்லாமல், தொடக்கத்தில் ஒரு முறை மட்டுமே சரிபார்க்கப்படும்.

எப்போது வலுவான தனிமைப்படுத்தலுக்குச் செல்ல வேண்டும்

வரிசை-நிலை பெரும்பாலானவர்களுக்கு வேலை செய்கிறது. ஆனால் சில வாடிக்கையாளர்களுக்கு இன்னும் அதிகம் தேவை.

வேண்டுமென்றே விரிவாக்குங்கள் (Escalate), தன்னிச்சையாக அல்ல:

• ஒழுங்குமுறை அல்லது ஒப்பந்த தனிமைப்படுத்தல் — ஒரு வாடிக்கையாளருக்கு அவர்களின் தரவு பௌதீக ரீதியாகத் தனித் தரவுத்தளத்தில் தேவைப்படுகிறது. ஒருவேளை அவர்கள் ஒழுங்குபடுத்தப்பட்ட துறையில் இருக்கலாம் அல்லது அதைக் கோரும் ஒப்பந்த ஷரத்தை வைத்திருக்கலாம்.
• சத்தமில்லாத-அண்டை வீட்டு அபாயம் (Noisy-neighbor risk) — ஒரு பெரிய வாடிக்கையாளரின் பணிச்சுமை மற்ற அனைவரின் செயல்திறனையும் குறைக்கிறது. தனி உள்கட்டமைப்பு இதைத் தீர்க்கிறது.
• ஒவ்வொரு வாடகைதாரருக்கும் தனிப்பயனாக்கம் — தரவு மட்டுமல்ல, ஸ்கீமாக்களும் உண்மையாகவே வேறுபடுகின்றன. வெவ்வேறு வாடிக்கையாளர்களுக்கு அடிப்படையான வெவ்வேறு கட்டமைப்புகளை நீங்கள் சேமிக்கிறீர்கள்.

அப்போதும் கூட, ஒரு கலப்பு (hybrid) நன்றாக வேலை செய்கிறது: பெரும்பாலான வாடகைதாரர்களை வரிசை-நிலையில் வைத்திருங்கள் மற்றும் உங்களின் மிகப்பெரிய அல்லது மிகவும் உணர்திறன் வாய்ந்த கணக்குகளை மட்டுமே பிரத்யேக தரவுத்தளங்களுக்கு மாற்றவும்.

முக்கியமான வடிவமைப்பு கோட்பாடுகள்

நீங்கள் எதைத் தேர்ந்தெடுத்தாலும், பல-வாடகைதாரர் அமைப்பை ஆரம்பத்திலேயே உட்பொதிக்கவும் (bake in). அதைப் பின்னால் சேர்க்க வேண்டாம்.

முக்கியமான எல்லா இடங்களிலும் tenant_id ஐ வைக்கவும்

சேர்க்கவும் tenant_id ஒவ்வொரு டொமைன் அட்டவணைக்கும், மேலும் அதனுடன் உங்கள் கலவை குறியீடுகளை (composite indexes) வழிநடத்தவும். இது வினவல்களை வேகமாக்குகிறது மற்றும் உங்கள் தரவை வாடகைதாரரால் இயல்பாகவே ஒழுங்கமைக்க வைக்கிறது.

வாடகைதாரர் அடையாளத்திற்காக கிளையண்டை (Client) ஒருபோதும் நம்ப வேண்டாம்

வாடகைதாரரை கோரிக்கை அளவுரு (request parameter) அல்லது குக்கீயிலிருந்து அல்லாமல், எப்போதும் அங்கீகரிக்கப்பட்ட அமர்விலிருந்து (authenticated session) பெறவும். நீங்கள் கிளையண்டிடம் "நீங்கள் எந்த வாடகைதாரர்?" என்று கேட்டால், ஒரு தீங்கிழைக்கும் அல்லது பிழையான கிளையண்ட் பொய் சொல்லலாம்.

தரவுத்தள அடுக்கில் தனிமைப்படுத்தலைச் செயல்படுத்தவும்

WHERE விதியை நினைவில் கொள்ள பயன்பாட்டை மட்டும் நம்ப வேண்டாம். தரவுக் கசிவை சாத்தியமற்றதாக்க தரவுத்தள கட்டுப்பாடுகள் மற்றும் RLS ஐப் பயன்படுத்தவும். ஒரு டெவலப்பர் எங்காவது ஒரு வடிகட்டியை மறந்துவிட்டால், தரவுத்தளமே அந்த தவறைத் தடுக்கிறது.

வாடகைதாரரை வழங்குதலை (Provisioning) ஒரு சோதிக்கப்பட்ட குறியீட்டுப் பாதையாக ஆக்குங்கள்

நீங்கள் புதிய வாடகைதாரரைச் சேர்க்கும்போது, தெளிவான, சோதிக்கப்பட்ட ஒரு செயல்முறையின் மூலம் இயக்கவும். குறியீட்டுத் தளத்தின் வெவ்வேறு பகுதிகள் வெவ்வேறு வழிகளில் வாடகைதாரர்களை உருவாக்க அனுமதிக்க வேண்டாம். நிலைத்தன்மை பிழைகளைத் தடுக்கிறது.

மிகவும் காயப்படுத்தும் தவறு

"தவறான" மாதிரியைத் தேர்ந்தெடுப்பது தவறல்ல. குறியீட்டுத் தளம் முழுவதும் வாடகைதாரரை மறைமுகமாக விட்டுவிட்டு, தனிமைப்படுத்தல் தர்க்கத்தை சிதறடிப்பதுதான். சில இறுதிப்புள்ளிகளில் WHERE விதிகளுடனும், மற்றவற்றில் SQL இணைப்புகளுடனும் முடிவடைகிறீர்கள், மேலும் தெளிவான விதி எதுவும் இல்லை.

பல-வாடகைதாரர் அமைப்பை மையப்படுத்துங்கள். தரவுத்தளத்தில் அதைச் செயல்படுத்தவும். ஒரு கொள்கையை ஒரு முறை அமைத்து, அங்கிருந்து உருவாக்குங்கள். பரிணாம வளர்ச்சி அடைவதற்கான சுதந்திரத்தை நீங்கள் வைத்திருக்கிறீர்கள்.

முடிவுரை

பல-வாடகைதாரர் கட்டமைப்பு ஒரு அடிப்படைத் தேர்வாகும். Postgres வரிசை-நிலை பாதுகாப்புடன் கூடிய வரிசை-நிலை வாடகைதாரர் அமைப்பே பெரும்பாலான SaaS-க்கான சரியான முன்னிருப்பு ஆகும் — இது மலிவானது, இது அளவிடப்படுகிறது, மேலும் தரவுத்தளம் தனிமைப்படுத்தலைச் செயல்படுத்துகிறது. ஒழுங்குமுறை, செயல்திறன் தனிமைப்படுத்தல் அல்லது உண்மையான ஸ்கீமா வேறுபாடு போன்ற தெளிவான காரணம் இருக்கும்போது மட்டுமே வலுவான வடிவங்களுக்குச் செல்லுங்கள். முதல் நாளிலிருந்தே அதை உருவாக்குங்கள், உங்கள் தேர்வை ஆவணப்படுத்துங்கள், மேலும் நீங்கள் சீராக அளவிடுவீர்கள்.

நன்மைகள்

• பெரும்பாலான தயாரிப்புகளுக்கு வரிசை-நிலை வாடகைதாரர் அமைப்பு செயல்பட மிகவும் மலிவானது மற்றும் எளிமையானது.
• Postgres வரிசை-நிலை பாதுகாப்பு தனிமைப்படுத்தல் தர்க்கத்தை தரவுத்தளத்திற்கு நகர்த்துகிறது, அங்கு அது வெளிப்படையாகச் செயல்படுத்தப்படுகிறது.
• ஒற்றைத் தரவுத்தளம், ஒரு ஸ்கீமா இடம்பெயர்வுகள் மற்றும் காப்புப்பிரதிகளை நேராக (straightforward) ஆக்குகிறது.
• கட்டமைப்பை மீண்டும் உருவாக்காமல் தனிப்பட்ட வாடகைதாரர்களை பின்னர் வலுவான தனிமைப்படுத்தலுக்கு நீங்கள் மேம்படுத்தலாம்.
• இந்த tenant_id + குறியீட்டு-முன்னணி (index-leading) வடிவம் பெரிய வாடிக்கையாளர் தளங்களுக்கு அளவிடப்படுகிறது.

தீமைகள்

• பௌதீகத் தரவுப் பிரிப்பைக் கோரும் ஒழுங்குமுறை அல்லது ஒப்பந்தத் தேவைகளுக்கு வரிசை-நிலை தனிமைப்படுத்தல் போதாது.
• ஒரே ஒரு சத்தமில்லாத (noisy) வாடகைதாரரின் கடுமையான வினவல்கள் ஒரே தரவுத்தளத்தில் உள்ள மற்ற வாடகைதாரர்களைப் பாதிக்கலாம்.
• RLS கொள்கைப் பிழைகள் (ஒவ்வொரு வரிசைக்கும் தர்க்கத்தை மீண்டும் மதிப்பிடுவது போன்றவை) அமைதியாகச் செயல்திறனைக் குறைக்கலாம்.
• வரிசை-நிலையிலிருந்து ஒவ்வொரு-வாடகைதாரருக்கும்-ஸ்கீமா அல்லது ஒவ்வொரு-வாடகைதாரருக்கும்-தரவுத்தளத்திற்கு பின்னர் மாறுவது சிக்கலானது மற்றும் ஆபத்தானது.
• வாடகைதாரர் வடிகட்டிகளை எப்போதும் சேர்க்க டெவலப்பர்கள் தங்களை ஒழுங்குபடுத்திக் கொள்ள வேண்டும் — தரவுத்தளம் உதவுகிறது, ஆனால் பயன்பாட்டுப் பிழைகள் இன்னும் சாத்தியமாகும்.

எச்சரிக்கை

இந்தக் கட்டுரை கல்வி சார்ந்தது மற்றும் பொதுவான சிறந்த நடைமுறைகளை அடிப்படையாகக் கொண்டது. மூலப்பொருள் ஒரு வலைப்பதிவு இடுகையிலிருந்து பெறப்பட்டது; கட்டமைப்பு முடிவுகளை எடுப்பதற்கு முன், உரிமைகோரல்கள் அசல் வெளியீட்டிற்கும் உங்கள் சொந்தத் தேவைகளுக்கும் எதிராகச் சரிபார்க்கப்பட வேண்டும். தொழில்துறை மற்றும் அதிகார வரம்பைப் பொறுத்து ஒழுங்குமுறை மற்றும் இணக்கத் தேவைகள் மாறுபடும் — உங்கள் குறிப்பிட்ட பயன்பாட்டிற்கு சட்ட மற்றும் பாதுகாப்பு நிபுணர்களை அணுகவும். உங்கள் சொந்தச் சூழலில் RLS கொள்கைகளை முழுமையாகச் சோதிக்கவும், குறிப்பாக அதிக அளவிலான செயல்திறன் நடத்தை (performance behavior at scale). இந்த கட்டுரை பணி-முக்கியமான அமைப்புகளுக்கான தொழில்முறை கட்டமைப்பு மதிப்பாய்வை மாற்றாது.

அடிக்கடி கேட்கப்படும் கேள்விகள்

• SaaS-ல் பல-வாடகைதாரர் (multi-tenancy) என்றால் என்ன, அது ஏன் முக்கியமானது?
• Postgres-ல் உள்ள வரிசை-நிலை பாதுகாப்பு எப்படி வாடகைதாரர்களிடையே தரவுக் கசிவைத் தடுக்கிறது?
• வரிசை-நிலை வாடகைதாரருக்குப் பதிலாக ஒவ்வொரு-வாடகைதாரருக்கும்-ஸ்கீமாவை (schema-per-tenant) நான் எப்போது பயன்படுத்த வேண்டும்?
• சத்தமில்லாத-அண்டை வீட்டு (noisy-neighbor) பிரச்சனை என்றால் என்ன, அது எப்படி SaaS கட்டமைப்பை பாதிக்கிறது?
• ஏற்கனவே உள்ள ஒற்றை-வாடகைதாரர் தரவுத்தளத்தில் நான் எப்படி tenant_id ஐச் சேர்ப்பது?
• நான் வரிசை-நிலையுடன் தொடங்கி, பின்னர் ஒவ்வொரு-வாடகைதாரருக்கும்-தரவுத்தளத்திற்கு மேம்படுத்த முடியுமா?
• அளவில் RLS கொள்கைகளின் செயல்திறன் தாக்கங்கள் என்ன?
• எனது பயன்பாட்டில் பல-வாடகைதாரர் தனிமைப்படுத்தலை (multi-tenant isolation) நான் எப்படிச் சோதிப்பது?

குறிச்சொற்கள்

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