ମଲ୍ଟି-ଟେନାଣ୍ଟ୍ SaaS ଆର୍କିଟେକ୍ଚର୍: ତିନୋଟି ପ୍ୟାଟର୍ଣ୍ଣ ଏବଂ କିପରି ବାଛିବେ

ମଲ୍ଟି-ଟେନାନ୍ସି ହେଉଛି ସେହି ଆର୍କିଟେକ୍ଚରାଲ୍ ନିଷ୍ପତ୍ତିଗୁଡ଼ିକ ମଧ୍ୟରୁ ଗୋଟିଏ ଯାହା ଆପଣଙ୍କର SaaS ବଢିବା ଆରମ୍ଭ କରିବା ପର୍ଯ୍ୟନ୍ତ ଆବ୍‌ଷ୍ଟ୍ରାକ୍ଟ ଅନୁଭବ କରେ। ତାପରେ ଏହା ସବୁକିଛିକୁ ଛୁଏଁ — ଆପଣ କିପରି ଡାଟା କ୍ୱେରୀ କରନ୍ତି, ଆପଣଙ୍କର ଡାଟାବେସ୍ ସ୍କେଲ୍ କରନ୍ତି, ମାଇଗ୍ରେସନ୍ ଚଲାନ୍ତି, ଏବଂ ଗ୍ରାହକ ଆଇସୋଲେସନ୍ ବିଷୟରେ ମଧ୍ୟ କିପରି ଭାବନ୍ତି। ଏହାକୁ ଆରମ୍ଭରୁ ସଠିକ୍ କରନ୍ତୁ, ଏବଂ ଆପଣ ହଜାର ହଜାର ଆକାଉଣ୍ଟକୁ ସହଜରେ ସ୍କେଲ୍ କରିବେ। ଏହାକୁ ଭୁଲ୍ କରନ୍ତୁ, ଏବଂ ଆପଣଙ୍କର ଗ୍ରାହକମାନେ ଦେଖୁଥିବା ବେଳେ ଆପଣ ମିଡ୍-ଗ୍ରୋଥ୍‌ରେ ଆପଣଙ୍କର ଡାଟା ଲେୟାରକୁ ପୁନର୍ବାର ଲେଖୁଥିବେ।

ଆଜି, 9 ଜୁଲାଇ 2026, ମଲ୍ଟି-ଟେନାଣ୍ଟ୍ SaaS ହେଉଛି ନର୍ମ୍, ବ୍ୟତିକ୍ରମ ନୁହେଁ। ଆପଣ ଟିମ୍ ପାଇଁ ଏକ ଟୁଲ୍ ତିଆରି କରୁଛନ୍ତି, ଏଣ୍ଟରପ୍ରାଇଜ୍‌କୁ ବିକ୍ରି କରୁଛନ୍ତି, କିମ୍ବା ୟୁଜେଜ୍-ବେସଡ୍ ପ୍ରାଇସିଂ ପ୍ରଦାନ କରୁଛନ୍ତି, ଆପଣ ଏହି ନିଷ୍ପତ୍ତି ନେଉଛନ୍ତି। ଖୁସିର ଖବର: ଅଧିକାଂଶ ପ୍ରଡକ୍ଟ ପାଇଁ, ସଠିକ୍ ଉତ୍ତର ଇଣ୍ଟରନେଟ୍ ଯାହା ପରାମର୍ଶ ଦିଏ ତାହା ଠାରୁ ସରଳ ଅଟେ।

ତିନୋଟି କାନୋନିକାଲ୍ ପ୍ୟାଟର୍ଣ୍ଣ

ଏକ SaaS ବ୍ୟାକେଣ୍ଡରେ ଟେନାଣ୍ଟ୍‌ମାନଙ୍କୁ ଆଇସୋଲେଟ୍ କରିବାର ତିନୋଟି ସୁପ୍ରତିଷ୍ଠିତ ଉପାୟ ଅଛି, ଏବଂ ସେଗୁଡିକ ଅପରେସନାଲ୍ କଷ୍ଟ୍ ବିରୁଦ୍ଧରେ ଆଇସୋଲେସନ୍‌କୁ ଟ୍ରେଡ୍ କରନ୍ତି।

ରୋ-ଲେଭେଲ୍ ଟେନାନ୍ସି (ସେୟାର୍ଡ ସ୍କିମା)

ପ୍ରତ୍ୟେକ ଟେବୁଲ୍‌ରେ ଏକ ଅଛି tenant_id କଲମ୍। ପ୍ରତ୍ୟେକ କ୍ୱେରୀ ଏହା ଉପରେ ଫିଲ୍ଟର୍ କରେ। ଗୋଟିଏ ଡାଟାବେସ୍, ଗୋଟିଏ ସ୍କିମା, ସମସ୍ତ ଟେନାଣ୍ଟ୍ ଏକାଠି। ଏହା ବୁଝିବା ପାଇଁ ସବୁଠାରୁ ସରଳ ପ୍ୟାଟର୍ଣ୍ଣ ଏବଂ ଅପରେଟ୍ କରିବା ପାଇଁ ସବୁଠାରୁ ଶସ୍ତା।

କଳ୍ପନା କରନ୍ତୁ ଆପଣ ଏକ ପ୍ରୋଜେକ୍ଟ-ମ୍ୟାନେଜମେଣ୍ଟ୍ ଟୁଲ୍ ତିଆରି କରୁଛନ୍ତି। ଆପଣଙ୍କର tasks ଟେବୁଲ୍ ପୃଥକ୍ ଷ୍ଟୋରେଜ୍‌ରେ ବିଭକ୍ତ ହୁଏ ନାହିଁ — ଏହା ପରିବର୍ତ୍ତେ, ପ୍ରତ୍ୟେକ ରୋ ସେହି ଟେନାଣ୍ଟ୍‌ର ଆଇଡି (ID) ବହନ କରେ ଯିଏ ଏହାର ମାଲିକ ଅଟେ। ଯେତେବେଳେ ଜଣେ ୟୁଜର୍ ସେମାନଙ୍କର ଟାସ୍କଗୁଡିକୁ କ୍ୱେରୀ କରନ୍ତି, ଆପ୍ଲିକେସନ୍ ଏକ WHERE କ୍ଲଜ୍ ଯୋଗ କରେ: WHERE tenant_id = current_user.tenant_id.

ସ୍କିମା-ପର୍-ଟେନାଣ୍ଟ୍

ପ୍ରତ୍ୟେକ ଟେନାଣ୍ଟ୍ ଏକ ସେୟାର୍ଡ ଡାଟାବେସ୍ ଭିତରେ ନିଜସ୍ୱ PostgreSQL ସ୍କିମା ପାଆନ୍ତି। ଅଧିକ ଶକ୍ତିଶାଳୀ ଆଇସୋଲେସନ୍, କାରଣ ପ୍ରତ୍ୟେକ ସ୍କିମା ଏହାର ନିଜସ୍ୱ ନେମ୍‌ସ୍ପେସ୍, କିନ୍ତୁ ପରିଚାଳନା କରିବାକୁ ଅଧିକ ଅବଜେକ୍ଟ। ମାଇଗ୍ରେସନ୍‌ଗୁଡିକ ଅଧିକ ଜଟିଳ ହୋଇଯାଏ — ଆପଣ ସେଗୁଡିକୁ ଏକାଧିକ ସ୍କିମା ମଧ୍ୟରେ ଚଲାଉଛନ୍ତି। ଏହି ପ୍ୟାଟର୍ଣ୍ଣ ରୋ-ଲେଭେଲ୍ ଏବଂ ପୂର୍ଣ୍ଣ ଆଇସୋଲେସନ୍ ମଧ୍ୟରେ ରହିଥାଏ।

ଡାଟାବେସ୍-ପର୍-ଟେନାଣ୍ଟ୍

ପ୍ରତ୍ୟେକ ଟେନାଣ୍ଟ୍ ଏକ ଡେଡିକେଟେଡ୍ ଡାଟାବେସ୍ କିମ୍ବା ଇନଷ୍ଟାନ୍ସ ପାଆନ୍ତି। ସର୍ବାଧିକ ଆଇସୋଲେସନ୍ — ଜଣେ ଟେନାଣ୍ଟ୍‌ର ଡାଟା ସମ୍ପୂର୍ଣ୍ଣ ପୃଥକ୍ ଷ୍ଟୋରେଜ୍‌ରେ ରହେ। ସର୍ବାଧିକ ଅପରେସନାଲ୍ ଭାର ମଧ୍ୟ — ଆପଣ ପ୍ରତ୍ୟେକ ଗ୍ରାହକ ପାଇଁ ପୃଥକ୍ ଡାଟାବେସ୍ ଇନଷ୍ଟାନ୍ସ, ବ୍ୟାକଅପ୍, ଏବଂ ଅପଗ୍ରେଡ୍ ପରିଚାଳନା କରୁଛନ୍ତି।

କାହିଁକି ରୋ-ଲେଭେଲ୍ ଅଧିକାଂଶ SaaS ପାଇଁ ଜିତେ

ଅଧିକାଂଶ B2B SaaS ପ୍ରଡକ୍ଟଗୁଡିକ ପାଇଁ, ରୋ-ଲେଭେଲ୍ ମଲ୍ଟି-ଟେନାନ୍ସି ହେଉଛି ସଠିକ୍ ଡିଫଲ୍ଟ। ଏହା ଅପରେଟ୍ କରିବା ପାଇଁ ସବୁଠାରୁ ଶସ୍ତା, ଏହା ବିରୁଦ୍ଧରେ ମାଇଗ୍ରେସନ୍ ଚଲାଇବା ପାଇଁ ସବୁଠାରୁ ସହଜ, ଏବଂ ଏହା ଫାଉଣ୍ଡର୍‌ମାନଙ୍କ ଆଶା ଠାରୁ ଅଧିକ ସ୍କେଲ୍ କରେ।

ଅବଜେକ୍ସନ୍ ସବୁବେଳେ ଥାଏ: "କିନ୍ତୁ ଆଇସୋଲେସନ୍ ବିଷୟରେ କ'ଣ?" ଏବଂ ଏଠାରେ Postgres ର ଏକ ଶକ୍ତିଶାଳୀ ଉତ୍ତର ଅଛି।

ରୋ-ଲେଭେଲ୍ ସିକ୍ୟୁରିଟି (RLS) ଏବଂ Postgres

Postgres ରୋ-ଲେଭେଲ୍ ସିକ୍ୟୁରିଟି ନାମକ ଏକ ଫିଚର୍ ପ୍ରଦାନ କରେ। RLS ଡାଟାବେସ୍‌କୁ ନିଜେ ଏହା ଏନଫୋର୍ସ କରିବାକୁ ଅନୁମତି ଦିଏ ଯେ ଏକ କ୍ୱେରୀ କେବଳ ନିଜ ଟେନାଣ୍ଟ୍‌ର ରୋଗୁଡିକୁ ଦେଖିପାରିବ। ଆପଣ ଥରେ ଏକ ପଲିସି ସେଟ୍ କରନ୍ତି — ସିଧାସଳଖ ଡାଟାବେସ୍‌ରେ — ଏବଂ ଏକ ବଗି କ୍ୱେରୀ ମଧ୍ୟ ଟେନାଣ୍ଟ୍‌ମାନଙ୍କ ମଧ୍ୟରେ ଡାଟା ଲିକ୍ କରିପାରିବ ନାହିଁ।

Supabase, ଏକ ହୋଷ୍ଟେଡ୍ Postgres ପ୍ଲାଟଫର୍ମ, RLS କୁ ନେଟିଭ୍ ମଡେଲ୍ କରେ। ଆପଣ ଏକ ପଲିସି ନିର୍ଦ୍ଧାରଣ କରନ୍ତି, ଏବଂ ଡାଟାବେସ୍ ଏକ ସିକ୍ୟୁରିଟି ବାଉଣ୍ଡାରୀ ହୋଇଯାଏ, କେବଳ ଆପ୍ଲିକେସନ୍ ଲେୟାର୍ ନୁହେଁ।

ଏହା ସହିତ ମିଶିତ ହୋଇ ଏକ tenant_id ପ୍ରତ୍ୟେକ ଟେବୁଲ୍‌ରେ ଏବଂ ଏକ ଇଣ୍ଡେକ୍ସ ଯାହା ଏହା ସହିତ ଲିଡ୍ କରେ, ଏହି ପ୍ୟାଟର୍ଣ୍ଣ ଆରାମରେ ବଡ଼ ଗ୍ରାହକ ବେସ୍‌କୁ ସର୍ଭ କରେ। ଡାଟାବେସ୍ ଏନଫୋର୍ସମେଣ୍ଟ୍ କରେ। ଆପ୍ଲିକେସନ୍‌କୁ ଫିଲ୍ଟର୍ କରିବାକୁ ମନେ ରଖିବାକୁ ପଡିବ ନାହିଁ।

RLS ଉପରେ ଏକ ବାସ୍ତବ ସତର୍କତା

ଅଭିଜ୍ଞତାରୁ ଗୋଟିଏ ଗୁରୁତ୍ୱପୂର୍ଣ୍ଣ ବିବରଣୀ: RLS ପଲିସିଗୁଡିକ ଲେଖନ୍ତୁ ଯାହା ଦ୍ୱାରା ହେଲ୍ପର୍ ଫଙ୍କସନ୍‌ଗୁଡିକ ପ୍ରତି କ୍ୱେରୀରେ ଥରେ ରନ୍ କରେ, ପ୍ରତି ରୋରେ ଥରେ ନୁହେଁ। ଏକ ପଲିସି ଯାହା ପ୍ରତ୍ୟେକ ରୋ ପାଇଁ ଏକ ଲୁକଅପ୍‌କୁ ପୁନଃ-ମୂଲ୍ୟାଙ୍କନ କରେ ତାହା ଟେବୁଲ୍ ବଢିବା ସହିତ ଧୀରେ ଧୀରେ ଫାଷ୍ଟ୍ ଏଣ୍ଡପଏଣ୍ଟ୍‌ଗୁଡିକୁ ସ୍ଲୋ କରିଦେବ। ଏହାର ସମାଧାନ ହେଉଛି ଚେକ୍‌କୁ ରାପ୍ କରିବା ଯାହା ଦ୍ୱାରା କ୍ୱେରୀ ପ୍ଲାନର୍ ଏହାକୁ ଏକ ଇନିଟ୍-ପ୍ଲାନ୍ ଭାବରେ ରନ୍ କରେ — ଆରମ୍ଭରେ ଏକ ୱାନ୍-ଟାଇମ୍ ଚେକ୍, ପର୍-ରୋ ନୁହେଁ।

କେବେ ଶକ୍ତିଶାଳୀ ଆଇସୋଲେସନ୍‌କୁ ଏସ୍କାଲେଟ୍ କରିବେ

ରୋ-ଲେଭେଲ୍ ଅଧିକାଂଶ ପାଇଁ କାମ କରେ। କିନ୍ତୁ କିଛି ଗ୍ରାହକ ଅଧିକ ଆବଶ୍ୟକ କରନ୍ତି।

ଜାଣିଶୁଣି ଏସ୍କାଲେଟ୍ କରନ୍ତୁ, ପ୍ରତିକ୍ରିୟାଶୀଳ ଭାବରେ ନୁହେଁ:

• ରେଗୁଲେଟୋରୀ କିମ୍ବା କଣ୍ଟ୍ରାକ୍ଚୁଆଲ୍ ଆଇସୋଲେସନ୍ — ଜଣେ ଗ୍ରାହକ ସେମାନଙ୍କ ଡାଟା ଏକ ଭୌତିକ ଭାବରେ ପୃଥକ୍ ଡାଟାବେସ୍‌ରେ ଆବଶ୍ୟକ କରନ୍ତି। ବୋଧହୁଏ ସେମାନେ ଏକ ନିୟନ୍ତ୍ରିତ ଇଣ୍ଡଷ୍ଟ୍ରିରେ ଅଛନ୍ତି କିମ୍ବା ଏହା ଦାବି କରୁଥିବା ଏକ କଣ୍ଟ୍ରାକ୍ଟ୍ କ୍ଲଜ୍ ଅଛି।
• ନଏଜି-ନେବର୍ ରିସ୍କ — ଜଣେ ହ୍ୱେଲ୍ ଗ୍ରାହକଙ୍କ ୱାର୍କଲୋଡ୍ ଅନ୍ୟ ସମସ୍ତଙ୍କ ପରଫର୍ମାନ୍ସକୁ ଖରାପ କରେ। ପୃଥକ୍ ଇନଫ୍ରାଷ୍ଟ୍ରକ୍ଚର୍ ଏହାର ସମାଧାନ କରେ।
• ପର୍-ଟେନାଣ୍ଟ୍ କଷ୍ଟମାଇଜେସନ୍ — ସ୍କିମାଗୁଡିକ ବାସ୍ତବରେ ଭିନ୍ନ ହୁଏ, କେବଳ ଡାଟା ନୁହେଁ। ଆପଣ ବିଭିନ୍ନ ଗ୍ରାହକଙ୍କ ପାଇଁ ମୌଳିକ ଭାବରେ ଭିନ୍ନ ଷ୍ଟ୍ରକ୍ଚର୍ ଷ୍ଟୋର୍ କରୁଛନ୍ତି।

ସେତେବେଳେ ମଧ୍ୟ, ଏକ ହାଇବ୍ରିଡ୍ ଭଲ କାମ କରେ: ଅଧିକାଂଶ ଟେନାଣ୍ଟ୍‌ଙ୍କୁ ରୋ-ଲେଭେଲ୍‌ରେ ରଖନ୍ତୁ ଏବଂ କେବଳ ଆପଣଙ୍କର ସବୁଠାରୁ ବଡ କିମ୍ବା ଅଧିକ ସମ୍ବେଦନଶୀଳ ଆକାଉଣ୍ଟ୍‌ଗୁଡିକୁ ଡେଡିକେଟେଡ୍ ଡାଟାବେସ୍‌କୁ ଗ୍ରାଜୁଏଟ୍ କରନ୍ତୁ।

ଡିଜାଇନ୍ ପ୍ରିନ୍ସିପଲ୍ସ ଯାହା ମ୍ୟାଟର୍ କରେ

ଆପଣ ଯାହା ବି ବାଛନ୍ତୁ, ମଲ୍ଟି-ଟେନାନ୍ସିକୁ ଆରମ୍ଭରୁ ବେକ୍ କରନ୍ତୁ। ଏହାକୁ ପରେ ବୋଲ୍ଟ ଅନ୍ କରନ୍ତୁ ନାହିଁ।

ଯେଉଁଠାରେ ଏହା ମ୍ୟାଟର୍ କରେ ସେଠାରେ tenant_id ରଖନ୍ତୁ

ଯୋଗ କରନ୍ତୁ tenant_id ପ୍ରତ୍ୟେକ ଡୋମେନ୍ ଟେବୁଲ୍‌କୁ ଏବଂ ଆପଣଙ୍କର କମ୍ପୋଜିଟ୍ ଇଣ୍ଡେକ୍ସଗୁଡିକୁ ଏହା ସହିତ ଲିଡ୍ କରନ୍ତୁ। ଏହା କ୍ୱେରୀଗୁଡିକୁ ଫାଷ୍ଟ୍ କରେ ଏବଂ ଆପଣଙ୍କର ଡାଟାକୁ ଟେନାଣ୍ଟ୍ ଅନୁଯାୟୀ ସ୍ୱାଭାବିକ ଭାବରେ ସଂଗଠିତ ରଖେ।

ଟେନାଣ୍ଟ୍ ଆଇଡେଣ୍ଟିଟି ପାଇଁ କ୍ଲାଏଣ୍ଟ୍ ଉପରେ କେବେ ବି ବିଶ୍ୱାସ କରନ୍ତୁ ନାହିଁ

ସର୍ବଦା ଅଥେଣ୍ଟିକେଟେଡ୍ ସେସନ୍‌ରୁ ଟେନାଣ୍ଟ୍ ଡିରାଇଭ୍ କରନ୍ତୁ, ରିକ୍ୱେଷ୍ଟ୍ ପାରାମିଟର୍ କିମ୍ବା କୁକିରୁ ନୁହେଁ। ଯଦି ଆପଣ କ୍ଲାଏଣ୍ଟ୍‌କୁ ପଚାରନ୍ତି "ଆପଣ କେଉଁ ଟେନାଣ୍ଟ୍?", ଏକ ମାଲିସିଅସ୍ କିମ୍ବା ବଗି କ୍ଲାଏଣ୍ଟ୍ ମିଛ କହିପାରେ।

ଡାଟାବେସ୍ ଲେୟାର୍‌ରେ ଆଇସୋଲେସନ୍ ଏନଫୋର୍ସ କରନ୍ତୁ

କେବଳ ଏହାର WHERE କ୍ଲଜ୍ ମନେ ରଖିବାକୁ ଆପ୍ଲିକେସନ୍ ଉପରେ ବିଶ୍ୱାସ କରନ୍ତୁ ନାହିଁ। ଡାଟା ଲିକ୍‌କୁ ଅସମ୍ଭବ କରିବାକୁ ଡାଟାବେସ୍ କନଷ୍ଟ୍ରେଣ୍ଟସ୍ ଏବଂ RLS ବ୍ୟବହାର କରନ୍ତୁ। ଯଦି ଜଣେ ଡେଭେଲପର୍ କେଉଁଠି ଫିଲ୍ଟର୍ ଭୁଲିଯାଆନ୍ତି, ତେବେ ଡାଟାବେସ୍ ନିଜେ ଭୁଲ୍‌କୁ ରୋକିଥାଏ।

ଟେନାଣ୍ଟ୍ ପ୍ରୋଭିଜନିଂକୁ ଏକ ଟେଷ୍ଟେଡ୍ କୋଡ୍ ପାଥ୍ କରନ୍ତୁ

ଯେତେବେଳେ ଆପଣ ଏକ ନୂଆ ଟେନାଣ୍ଟ୍ ଯୋଗ କରନ୍ତି, ଗୋଟିଏ ସ୍ପଷ୍ଟ, ଟେଷ୍ଟେଡ୍ ପ୍ରୋସେସ୍ ମାଧ୍ୟମରେ ରନ୍ କରନ୍ତୁ। କୋଡବେସ୍‌ର ବିଭିନ୍ନ ଅଂଶକୁ ବିଭିନ୍ନ ଉପାୟରେ ଟେନାଣ୍ଟ୍ ତିଆରି କରିବାକୁ ଦିଅନ୍ତୁ ନାହିଁ। କନସିଷ୍ଟେନ୍ସି ବଗ୍ ରୋକିଥାଏ।

ଯେଉଁ ଭୁଲ୍ ସବୁଠାରୁ ଅଧିକ କଷ୍ଟ ଦିଏ

ଭୁଲ୍ "ଭୁଲ୍" ମଡେଲ୍ ବାଛିବା ନୁହେଁ। ଏହା ଟେନାନ୍ସିକୁ ଇମ୍ପ୍ଲିସିଟ୍ ଛାଡିବା ଏବଂ କୋଡବେସ୍ ମଧ୍ୟରେ ଆଇସୋଲେସନ୍ ଲଜିକ୍ ସ୍କାଟର୍ କରିବା ଅଟେ। ଆପଣ କିଛି ଏଣ୍ଡପଏଣ୍ଟ୍‌ରେ WHERE କ୍ଲଜ୍, ଅନ୍ୟଗୁଡିକରେ SQL ଜଏନ୍, ଏବଂ କୌଣସି ସ୍ପଷ୍ଟ ନିୟମ ନଥିବାର ଦେଖିବେ।

ମଲ୍ଟି-ଟେନାନ୍ସିକୁ ସେଣ୍ଟ୍ରାଲାଇଜ୍ କରନ୍ତୁ। ଏହାକୁ ଡାଟାବେସ୍‌ରେ ଏନଫୋର୍ସ କରନ୍ତୁ। ଥରେ ଏକ ପଲିସି ସେଟ୍ କରନ୍ତୁ ଏବଂ ସେଠାରୁ ବିଲ୍ଡ କରନ୍ତୁ। ଆପଣ ଇଭୋଲ୍ଭ କରିବାର ସ୍ୱାଧୀନତା ବଜାୟ ରଖନ୍ତି।

ଉପସଂହାର

ମଲ୍ଟି-ଟେନାଣ୍ଟ୍ ଆର୍କିଟେକ୍ଚର୍ ହେଉଛି ଏକ ଫାଉଣ୍ଡେସନାଲ୍ ଚଏସ୍। ପୋଷ୍ଟଗ୍ରେସ୍ ରୋ-ଲେଭେଲ୍ ସିକ୍ୟୁରିଟି ସହିତ ରୋ-ଲେଭେଲ୍ ଟେନାନ୍ସି ଅଧିକାଂଶ SaaS ପାଇଁ ସଠିକ୍ ଡିଫଲ୍ଟ ଅଟେ — ଏହା ଶସ୍ତା, ଏହା ସ୍କେଲ୍ କରେ, ଏବଂ ଡାଟାବେସ୍ ଆଇସୋଲେସନ୍ ଏନଫୋର୍ସ କରେ। ଯେତେବେଳେ ଆପଣଙ୍କ ପାଖରେ ଏକ ସ୍ପଷ୍ଟ କାରଣ ଥାଏ ସେତେବେଳେ କେବଳ ଶକ୍ତିଶାଳୀ ପ୍ୟାଟର୍ଣ୍ଣକୁ ଏସ୍କାଲେଟ୍ କରନ୍ତୁ: ରେଗୁଲେସନ୍, ପରଫର୍ମାନ୍ସ ଆଇସୋଲେସନ୍, କିମ୍ବା ପ୍ରକୃତ ସ୍କିମା ଡାଇଭର୍ଜେନ୍ସ। ଏହାକୁ ପ୍ରଥମ ଦିନରୁ ବିଲ୍ଡ କରନ୍ତୁ, ଆପଣଙ୍କର ଚଏସ୍ ଡକ୍ୟୁମେଣ୍ଟ୍ କରନ୍ତୁ, ଏବଂ ଆପଣ ସହଜରେ ସ୍କେଲ୍ କରିବେ।

ମେରିଟ୍ସ

• ରୋ-ଲେଭେଲ୍ ଟେନାନ୍ସି ଅଧିକାଂଶ ପ୍ରଡକ୍ଟ ପାଇଁ ଅପରେଟ୍ କରିବା ପାଇଁ ସବୁଠାରୁ ଶସ୍ତା ଏବଂ ସରଳ ଅଟେ।
• Postgres ରୋ-ଲେଭେଲ୍ ସିକ୍ୟୁରିଟି ଆଇସୋଲେସନ୍ ଲଜିକ୍‌କୁ ଡାଟାବେସ୍‌କୁ ନେଇଯାଏ, ଯେଉଁଠାରେ ଏହା ଟ୍ରାନ୍ସପ୍ୟାରେଣ୍ଟ୍ ଭାବରେ ଏନଫୋର୍ସ ହୁଏ।
• ସିଙ୍ଗଲ୍ ଡାଟାବେସ୍, ଗୋଟିଏ ସ୍କିମା ମାଇଗ୍ରେସନ୍ ଏବଂ ବ୍ୟାକଅପ୍‌କୁ ସହଜ କରେ।
• ଆପଣ ପରେ ରିଆର୍କିଟେକ୍ଟ୍ ନକରି ବ୍ୟକ୍ତିଗତ ଟେନାଣ୍ଟ୍‌ମାନଙ୍କୁ ଶକ୍ତିଶାଳୀ ଆଇସୋଲେସନ୍‌କୁ ଅପଗ୍ରେଡ୍ କରିପାରିବେ।
• ଏହି tenant_id + ଇଣ୍ଡେକ୍ସ-ଲିଡିଂ ପ୍ୟାଟର୍ଣ୍ଣ ବଡ଼ ଗ୍ରାହକ ବେସ୍‌କୁ ସ୍କେଲ୍ କରେ।

ଡିମେରିଟ୍ସ

• ଭୌତିକ ଡାଟା ପୃଥକୀକରଣ ଦାବି କରୁଥିବା ରେଗୁଲେଟୋରୀ କିମ୍ବା କଣ୍ଟ୍ରାକ୍ଚୁଆଲ୍ ଆବଶ୍ୟକତା ପାଇଁ ରୋ-ଲେଭେଲ୍ ଆଇସୋଲେସନ୍ ଯଥେଷ୍ଟ ନୁହେଁ।
• ଗୋଟିଏ ନଏଜି ଟେନାଣ୍ଟ୍‌ର ଭାରୀ କ୍ୱେରୀଗୁଡିକ ସମାନ ଡାଟାବେସ୍‌ରେ ଅନ୍ୟ ଟେନାଣ୍ଟ୍‌ମାନଙ୍କୁ ପ୍ରଭାବିତ କରିପାରେ।
• RLS ପଲିସି ଭୁଲ୍ (ଯେପରିକି ପ୍ରତି ରୋରେ ଲଜିକ୍ ପୁନଃ-ମୂଲ୍ୟାଙ୍କନ କରିବା) ନୀରବରେ ପରଫର୍ମାନ୍ସକୁ ଟ୍ୟାଙ୍କ୍ କରିପାରେ।
• ରୋ-ଲେଭେଲ୍‌ରୁ ସ୍କିମା-ପର୍-ଟେନାଣ୍ଟ୍ କିମ୍ବା ଡାଟାବେସ୍-ପର୍-ଟେନାଣ୍ଟ୍‌କୁ ପରେ ମାଇଗ୍ରେଟ୍ କରିବା ଜଟିଳ ଏବଂ ବିପଦପୂର୍ଣ୍ଣ ଅଟେ।
• ସର୍ବଦା ଟେନାଣ୍ଟ୍ ଫିଲ୍ଟର୍ ଅନ୍ତର୍ଭୁକ୍ତ କରିବାକୁ ଡେଭେଲପର୍‌ମାନେ ନିଜକୁ ଶୃଙ୍ଖଳିତ କରିବା ଆବଶ୍ୟକ — ଡାଟାବେସ୍ ସାହାଯ୍ୟ କରେ, କିନ୍ତୁ ଆପ୍ଲିକେସନ୍ ବଗ୍ ଏବେ ବି ସମ୍ଭବ।

ସତର୍କତା

ଏହି ଲେଖାଟି ଶିକ୍ଷଣୀୟ ଏବଂ ସାଧାରଣ ସର୍ବୋତ୍ତମ ଅଭ୍ୟାସ ଉପରେ ଆଧାରିତ। ଉତ୍ସ ସାମଗ୍ରୀ ଏକ ବ୍ଲଗ୍ ପୋଷ୍ଟରୁ ଆସିଛି; ଆର୍କିଟେକ୍ଚରାଲ୍ ନିଷ୍ପତ୍ତି ନେବା ପୂର୍ବରୁ ଦାବିଗୁଡିକ ମୂଳ ପ୍ରକାଶନ ଏବଂ ଆପଣଙ୍କ ନିଜର ଆବଶ୍ୟକତା ବିରୁଦ୍ଧରେ ଯାଞ୍ଚ କରାଯିବା ଉଚିତ୍। ଶିଳ୍ପ ଏବଂ କ୍ଷେତ୍ରାଧିକାର ଅନୁଯାୟୀ ନିୟାମକ ଏବଂ ଅନୁପାଳନ ଆବଶ୍ୟକତା ଭିନ୍ନ ହୋଇଥାଏ — ଆପଣଙ୍କର ନିର୍ଦ୍ଦିଷ୍ଟ ୟୁଜ୍ କେସ୍ ପାଇଁ ଆଇନଗତ ଏବଂ ସୁରକ୍ଷା ବିଶେଷଜ୍ଞଙ୍କ ସହିତ ପରାମର୍ଶ କରନ୍ତୁ। ଆପଣଙ୍କ ନିଜ ପରିବେଶରେ RLS ପଲିସିଗୁଡିକ ଭଲଭାବେ ପରୀକ୍ଷା କରନ୍ତୁ, ବିଶେଷକରି ସ୍କେଲ୍‌ରେ ପରଫର୍ମାନ୍ସ ବ୍ୟବହାର। ଏହି ଲେଖା ମିଶନ୍-କ୍ରିଟିକାଲ୍ ସିଷ୍ଟମ୍ ପାଇଁ ପ୍ରଫେସନାଲ୍ ଆର୍କିଟେକ୍ଚର୍ ରିଭ୍ୟୁର ବିକଳ୍ପ ନୁହେଁ।

ବାରମ୍ବାର ପଚରାଯାଉଥିବା ପ୍ରଶ୍ନ (FAQs)

• SaaS ରେ ମଲ୍ଟି-ଟେନାନ୍ସି କ'ଣ ଏବଂ ଏହା କାହିଁକି ଗୁରୁତ୍ୱପୂର୍ଣ୍ଣ?
• Postgres ରେ ରୋ-ଲେଭେଲ୍ ସିକ୍ୟୁରିଟି ଟେନାଣ୍ଟ୍‌ମାନଙ୍କ ମଧ୍ୟରେ ଡାଟା ଲିକ୍‌କୁ କିପରି ରୋକିଥାଏ?
• ରୋ-ଲେଭେଲ୍ ଟେନାନ୍ସି ପରିବର୍ତ୍ତେ ମୁଁ କେବେ ସ୍କିମା-ପର୍-ଟେନାଣ୍ଟ୍ ବ୍ୟବହାର କରିବା ଉଚିତ୍?
• ନଏଜି-ନେବର୍ ସମସ୍ୟା କ'ଣ ଏବଂ ଏହା SaaS ଆର୍କିଟେକ୍ଚର୍‌କୁ କିପରି ପ୍ରଭାବିତ କରେ?
• ମୁଁ ଏକ ବିଦ୍ୟମାନ ସିଙ୍ଗଲ୍-ଟେନାଣ୍ଟ୍ ଡାଟାବେସ୍‌ରେ tenant_id କିପରି ଯୋଗ କରିବି?
• ମୁଁ ରୋ-ଲେଭେଲ୍ ସହିତ ଆରମ୍ଭ କରିପାରିବି ଏବଂ ପରେ ଡାଟାବେସ୍-ପର୍-ଟେନାଣ୍ଟ୍‌କୁ ଅପଗ୍ରେଡ୍ କରିପାରିବି କି?
• ସ୍କେଲ୍‌ରେ RLS ପଲିସିଗୁଡିକର ପରଫର୍ମାନ୍ସ ଇମ୍ପ୍ଲିକେସନ୍‌ଗୁଡିକ କ'ଣ?
• ମୁଁ ମୋର ଆପ୍ଲିକେସନ୍‌ରେ ମଲ୍ଟି-ଟେନାଣ୍ଟ୍ ଆଇସୋଲେସନ୍ କିପରି ଟେଷ୍ଟ୍ କରିବି?

ଟ୍ୟାଗ୍‌ଗୁଡ଼ିକ

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