Monolith Veritabanında Tenant İzolasyonu: Ne Zaman Şemalar Yetersiz Kalır

Çok kiracılı (multi-tenant) bir SaaS uygulaması yazıyorsun. Maliyeti düşük tutmak için tüm müşterileri tek bir veritabanında barındıracaksın. Basit çözüm: her kiracı için ayrı şema. bu kadar basit değil.

Şema izolasyonu (schema isolation), yani her kiracının kendi tablo setine sahip olması, teoride güvenli görünür. Pratik olarak? Ciddi sorunlarla karşılaşırsın.

İlk sorun performans. Binlerce şema varsa, sorgu planlayıcı (query planner) her seferinde hangi şemaya erişeceğini kararlaştırmak zorunda kalır. Veritabanı bağlantı havuzu (connection pool) da patlar: her şema için ayrı bağlantı açmak gerekir. bağlantı sayısı kontrol dışına çıkar, veritabanı sunucu kaynakları bitebilir. Bir müşteri ani bir sorgu yağmurı gönderirse, diğer müşterileri etkilemesen bile, altyapı yükü ciddi artar.

İkinci sorun: veri sızıntısı riski azalmıyor, sadece başka şekle giriyor. Şema adını kiracı kimliğinden türetiyorsan (örneğin tenant_123), kötü niyetli biri tahmin etme yoluyla başka kiracının şemasına erişmeye çalışabilir. Uygulama katmanında kiracı doğrulaması yapmalısın yine de. Şema izolasyonu güvenlik katmanı değildir; yalnızca veri organizasyonudur.

Üçüncü sorun: bakım kabusu. Şema güncellemesi yapacaksın (yeni sütun, indeks, veri tipi değişikliği). Bin şemaya birer birer uygula. Hepsi başarılı mı? Hangisi başarısız oldu? Rollback işlemi ne kadar sürer? Veritabanı migrasyonlar ciddi bir operasyonel yük haline gelir.

Dördüncü: raporlama ve analitik. Tüm kiracılar arası bir rapor çekmek istiyorsun (toplam gelir, aktif kullanıcı sayısı vb.). Bin şemayı birleştirmek gerekir. UNION ALL sorguları yazarsın, performans berbat olur.

Şemalar ne zaman yetersiz kalır? Kiracı sayısı 50-100'ü geçtiğinde, bağlantı havuzu ve sorgu planlayıcısı sorunları ciddi hale gelir. Kiracılar arası veri bütünlüğü sorgularına ihtiyaç duyarsan (örneğin denetim günlüğü), şemalar arasında JOIN yapman gerekir, bu hem yavaş hem hatalı olur.

Gerçekçi alternatif: tek şema, kiracı kimliği (tenant_id) sütunu. Tüm tablolarda tenant_id olur, satır düzeyinde güvenlik (row-level security) veya uygulama katmanında doğrulama yaparsın. Sorgu planlayıcı tutarlı kalır, bağlantı havuzu yönetilebilir, migrasyonlar basit hale gelir. Ödül: tüm kiracılar arası sorgular doğal olur.

Şema izolasyonu sadece çok özel durumlarda mantıklı: kiracılar arasında tam veri izolasyonu gerekiyorsa (örneğin yasal zorunluluk), ya da kiracı sayısı hiç artmayacaksa. Aksi takdirde, ölçeklenebilir bir sistem kurmak istiyorsan, satır düzeyinde izolasyon daha sağlıklıdır.