در یک محصول SaaS، چند مشتری یا مستأجر از یک نرمافزار واحد استفاده میکنند و دادههای آنها باید کاملاً از هم جدا بماند. سه الگوی اصلی برای این جداسازی وجود دارد: پایگاه دادهٔ مجزا برای هر مستأجر، اسکیمای مجزا در یک پایگاه داده، یا جدولهای مشترک با ستون tenant_id. انتخاب میان این سه، یکی از مهمترین تصمیمهای معماری در توسعهٔ نرمافزار SaaS است.
الگوی پایگاه دادهٔ مجزا بیشترین جداسازی و امنیت را میدهد و پشتیبانگیری یا بازیابی هر مشتری مستقل است. اما با رشد تعداد مشتریان، مدیریت صدها پایگاه داده و اجرای مهاجرت اسکیما روی همهٔ آنها پرهزینه و کند میشود. این الگو برای تعداد محدود مشتریان بزرگ با نیاز انطباق سختگیرانه مناسب است.
الگوی جدول مشترک با tenant_id سادهترین برای مقیاسپذیری است؛ یک اسکیما، یک مهاجرت و استفادهٔ بهینه از منابع. ریسک اصلی، نشت داده میان مستأجرهاست اگر یک کوئری شرط tenant_id را فراموش کند. ما این ریسک را با Row-Level Security در PostgreSQL کنترل میکنیم تا پایگاه داده خودش در سطح سطر، دسترسی را محدود کند و خطای انسانی فاجعهبار نشود.
در عمل، ما اغلب رویکرد ترکیبی را پیشنهاد میدهیم: جدول مشترک بهعنوان پیشفرض برای اکثر مشتریان، و امکان جابهجایی مشتریان بزرگ یا حساس به پایگاه دادهٔ اختصاصی. مهم این است که لایهٔ دسترسی به داده از همان ابتدا با مفهوم مستأجر طراحی شود تا تغییر الگو در آینده بدون بازنویسی کل اپلیکیشن ممکن باشد.