Database düzeyinde tenant isolation tercihi, ileride binlerce müşteri olduğunda kararınızı yargılayacak.
Bu yazıda konuyu üretim deneyimimizden 5 maddeyle açıyoruz: hangi durumda hangi tercih kazanır, hangi tuzaklara dikkat etmek gerekir, ve 2026'da hâlâ yararlı olan kararlar nelerdir. Bizim 12 yılda 9 ürün yayınlarken karşılaştığımız gerçek senaryolar bu yazının kaynağı — pazarlama içeriği değil, mühendislik notu.
1. Pool model — tek DB, tenant_id sütunu
En ucuz, en hızlı. Tek Postgres, her tabloda tenant_id kolonu. Index'ler tenant_id'ye dahil olmalı. Veri sızıntısı en yüksek risk; ORM seviyesinde global filter şart.
Bu noktayı bizim üretim ortamımızda nasıl uyguladığımızdan örnek: ilk projede kararı çabuk verdik ve sonra geri döndük. O günden beri her yeni projede aynı kontrolü 30 dakikada yapıyoruz; süreç bizi çok kazandırıyor.
2. Silo model — tenant başı ayrı DB
Pahalı ama izolasyon mükemmel. Enterprise müşteri için "veriniz tek başına bir DB'de" sözünü tutmanın tek yolu. Migration'lar 5×, fatura 3× yüksek.
Bu noktayı bizim üretim ortamımızda nasıl uyguladığımızdan örnek: ilk projede planlamayı 2 hafta uzattık. Erken kararın geç bakım maliyeti her zaman daha düşük olduğunu öğrendik.
3. Hibrit — bizim önerimiz
Standart müşteriler pool'da, enterprise müşteriler silo'da. Aynı kod tabanı, farklı connection string. bubi ADS'te 6.500 müşteriden 14'ü silo'da.
Bu noktayı bizim üretim ortamımızda nasıl uyguladığımızdan örnek: ilk projede planlamayı 2 hafta uzattık. Erken kararın geç bakım maliyeti her zaman daha düşük olduğunu öğrendik.
- Hızlı kazanç: İlk hafta uygulayın
- Orta vade: 30 günlük sprint planına ekleyin
- Uzun vade: Çeyreklik metric'lerinizi yeniden tanımlayın
4. Row-level security (RLS) — Postgres süper gücü
Pool modelinde sızıntı riskini büyük oranda kapatır. CREATE POLICY tenant_isolation ON ... USING (tenant_id = current_setting('app.tenant_id')::uuid). ORM bypass etse bile DB durdurur.
Bu noktayı bizim üretim ortamımızda nasıl uyguladığımızdan örnek: ilk projede planlamayı 2 hafta uzattık. Erken kararın geç bakım maliyeti her zaman daha düşük olduğunu öğrendik.
5. Migration stratejisi — pool'dan silo'ya geçiş
Müşteri sözleşmesinde silo isteyince ne olur? pg_dump + restore + DNS değişikliği. Ortalama 4 saat downtime; geceleri planlayın.
Bu noktayı bizim üretim ortamımızda nasıl uyguladığımızdan örnek: ilk projede planlamayı 2 hafta uzattık. Erken kararın geç bakım maliyeti her zaman daha düşük olduğunu öğrendik.
Sık sorulan sorular
Multi-tenant SaaS mimarisi ne kadar sürer?
Senaryoya göre değişir; bizim uygulamalarımızda ilk değer 2-4 hafta, tam yapı 8-12 hafta. Bu yazıda detayları paylaştık.
Bu yaklaşımın bütçesi nedir?
Konuya göre değişiyor — ücretsiz ön görüşmemizde gerçek brief üzerinden tahmin veriyoruz.
Türkiye dışı projelerde de aynı tavsiyeler geçerli mi?
Genelde evet; sadece KVKK / vergi tarafları ülkeye göre değişir.