Ayrı database: güçlü izolasyon, yüksek operasyon yükü
Her tenant için ayrı database açmak izolasyon açısından anlaşılır bir modeldir. Bir müşterinin verisini taşımak, yedeklemek, silmek veya kaynaklarını ayırmak daha kolaydır. Büyük kurumsal müşteriler için bu model güven verir.
Bedeli ise operasyon sayısıdır. Yüzlerce tenant varsa yüzlerce connection string, migration, yedek, izleme ve kapasite kararı doğar. Otomasyon yoksa ekip hızla yorulur.
- Kurumsal veya regülasyon hassas müşteriler için güçlü adaydır.
- Müşteri çıkışı ve özel yedek daha kolay yönetilir.
- Migration ve sürüm yönetimi otomasyon ister.
- Küçük tenant sayısı çok fazlaysa maliyet artabilir.
Ayrı schema: orta yol gibi görünür
Ayrı schema yaklaşımı aynı database içinde tenantları mantıksal olarak ayırır. Migration yönetimi ayrı database kadar ağır olmayabilir; ama yine de schema sayısı arttıkça operasyon karmaşası büyür.
Bu model, orta ölçekli SaaS ürünlerinde mantıklı olabilir. Ancak connection, yetki ve search_path gibi detaylar dikkatle yönetilmelidir.
tenant_id kolonu: ekonomik ama disiplin ister
Tek schema içinde her tabloda tenant_id kullanmak maliyet ve operasyon açısından verimlidir. Ancak güvenlik riski uygulama koduna daha çok yüklenir. Bir sorguda tenant filtresi unutulursa veri sızıntısı riski oluşur.
Bu modelde row-level security, testler, kod inceleme ve standart query helperları çok önemlidir. Sadece “geliştiriciler dikkat eder” demek yeterli güvenlik modeli değildir.
PostgreSQL RLS fikri
alter table orders enable row level security;
create policy tenant_isolation_orders on orders
using (tenant_id = current_setting('app.tenant_id')::bigint);RLS güçlü bir araçtır; uygulama bağlantı ve session ayarları doğru kurulmadan tek başına yeterli değildir.
Kararı müşteri segmentiyle birlikte verin
Aynı üründe tek model kullanmak zorunda değilsiniz. Küçük müşteriler ortak tablo modelinde, büyük müşteriler ayrı database modelinde tutulabilir. Hibrit yaklaşım karmaşıktır ama ticari gerçekliği daha iyi karşılayabilir.
Kararı verirken yedek, geri yükleme, müşteri çıkışı, veri silme, maliyet, performans ve destek erişimi birlikte düşünülmelidir.
Tenant model karar matrisi
Müşteri segmenti: Veri hassasiyeti: Beklenen veri boyutu: Özel yedek/restore ihtiyacı: Müşteri çıkışı beklentisi: Maliyet hassasiyeti: Önerilen model: ayrı database / ayrı schema / tenant_id / hibrit