Her multi-tenant SaaS projesinin ilk mimari kararı budur: tenant verilerini nasıl ayıracaksın? Geçen 4 yılda 3 farklı SaaS ürünü kurdum, üçünde de farklı izolasyon modeli tercih ettim, ve üçü de doğru karardı, çünkü bağlam farklıydı.
Row-level tenant_id, çoğunluğun başlangıç noktası
En yaygın model: her tabloya bir tenant_id kolonu ekliyorsun, bütün query’lerde WHERE clause’una bunu ekliyorsun. Çok kiracılı SaaS’ların belki %80’i bu şekilde başlar. İlk sezgisel çekiciliği var:
- Tek bir veritabanı, tek bir bağlantı havuzu
- Migration’lar tek seferde, her tenant için ayrı ayrı değil
- Yeni tenant eklemek sadece bir satır insert
Ama şu üç durumdan biri varsa yolun sonunda başın ağrır:
- Tenant başına veri hacmi çok farklı oluyorsa. 10K satır olan kiracıyla 10M satır olan kiracı aynı tabloda yaşıyor. Index seçicilik düşüyor, büyük tenant yavaş query’lerle küçük tenantların deneyimini öldürüyor.
- Enterprise müşteri “benim verim ayrı bir sunucuda dursun” diyorsa. Row-level ile bunu temiz bir şekilde sunmak neredeyse imkansız.
- GDPR/KVKK talebi “X tenant’ın tüm verisini hemen sil” dediğinde cascade delete’lerin ne kadar sürdüğünü göreceksin.
Schema-level, enterprise’ın istediği
Her tenant için ayrı bir schema (PostgreSQL’de CREATE SCHEMA, MySQL’de ayrı bir database). Tablolar aynı, veriler ayrı.
Enterprise müşteri için altın standart. Audit, backup, export, delete, hepsi tenant bazında izole. “Veriniz sadece size ait bir alanda” diyebilirsin ve bu teknik olarak doğru.
Ama operasyonel maliyeti ciddi:
- Migration çalıştırmak: N tenant varsa N kere çalıştırıyorsun. Bir migration 2 dakika sürüyorsa 500 tenant = 1000 dakika = 16 saat
- Connection pool’u schema başına ayarlamak gerekebilir
- Yeni bir bakım sırasında “hangi tenant’larda hata oldu” sorusunun cevabı ayrı bir izleme katmanı gerektirir
Database-level, sadece gerçekten büyük müşterilerde
Her tenant için ayrı bir veritabanı instance. Genelde sadece “bu tenant bize yılda 6 haneli ödüyor” seviyesinde müşteriler için mantıklı.
Bu noktada artık SaaS yerine managed hosting yapıyorsun, kabul etmek lazım. Mimari olarak temiz, ama operasyon ekibi olmadan sürdürülemez.
Pratik karar kriterleri
Başlangıç aşamasındaki bir ürüne danışmanlık verirken sorduğum sorular:
- İlk enterprise müşterin ne zaman gelecek? Önümüzdeki 12 ayda gelmeyecekse row-level başla, o zaman düşünürüz.
- Tenant başına veri büyüklüğü sabit mi yoksa kullanıma göre çok değişecek mi? Çok değişecekse erken schema-level düşün.
- “Verimi bana teslim et” talebi olacak mı? Olacaksa schema-level baştan planla.
- Compliance gereksinimin var mı (SOC 2, HIPAA, KVKK)? Bunların hepsi tenant izolasyonunu kontrol ediyor, schema-level’ı kolaylaştırır.
Sonuç
Doğru cevap yok, iyi analiz var. Ürünün 6-12 ay sonra nereye gideceğini bilmeden mimari kararı vermek istersen row-level ile başla, ama migration path’ini peşin düşün. 2-3 yıl sonra schema-level’a geçmek 6 haftalık bir proje olur, başta planlanmamışsa 3-4 aya çıkabiliyor.
Karar verirken sadece bugünkü ihtiyacı değil, 2 yıl sonraki senaryoyu düşünün.