# Multi-tenant SaaS'ta veritabanı izolasyonu: ayrı DB mi, şema mı, tenant_id mi?

> 10.000 tenant'ta database-per-tenant operasyonel olarak ölçeklenmez; her tabloda tenant_id tutup izolasyonu Postgres Row-Level Security'ye gömün.

- Soruldu: 2026-05-12
- Yanıtlandı: 2026-05-15
- Soran: Berk
- Etiketler: mimari, veritabani, olcekleme
- Kaynak: https://www.muhammetsafak.com.tr/sor-bakalim/multi-tenant-saas-veritabani-izolasyon-stratejisi/
- Dil: tr-TR
- Yazar: Muhammet Şafak

---
**Soru:** Yeni bir SaaS geliştiriyorum; müşteri (tenant) verilerini izole etmem gerek. Üç seçenek var: her müşteriye ayrı DB (database-per-tenant), aynı DB'de ayrı şemalar (schema-per-tenant), ya da tek DB'de `tenant_id` kolonu (shared).

Güvenlik, yedekleme kolaylığı, maliyet ve şema migration'ı düşünerek 10.000 aktif müşteriye ölçeklenecek en optimum mimariyi nasıl seçerim?


Kısa cevap: 10.000 tenant ölçeğinde pragmatik cevap, her yerde `tenant_id` olan **shared** bir DB + izolasyonu **Postgres Row-Level Security**'ye gömmek.

Önce neden diğer ikisini elediğimi söyleyeyim, çünkü karar bu sayıda operasyona bakar:

1. **Database-per-tenant 10.000'de ölçeklenmez.** Her tenant için ayrı DB demek 10.000 migration, 10.000 connection pool, 10.000 backup işi demek. İzolasyonu mükemmel verir ama operasyonel yükü altında ezilirsiniz. Bu, ancak az sayıda büyük müşteride mantıklı.
2. **Schema-per-tenant orta yol ama o da zorlanır.** Tek DB'de ayrı şema, izolasyon ile yönetim arasında bir köprü; fakat 10k şemada katalog (catalog) şişer, migration hâlâ N kere koşar. Birkaç yüz tenant'a kadar iyi, on bine değil.
3. **Shared DB + her yerde `tenant_id`.** Tek şema, her tabloda `tenant_id`. Backup ve migration en basit burada — tek DB, tek migration. Maliyet de burada en düşük: 10.000 tenant için tek instance'ın kaynağını paylaşırsınız, tenant başına ayrı DB'nin taban maliyetini ödemezsiniz. Takas ettiğiniz şey güvenlik; onu da RLS ile geri satın alırsınız.
4. **İzolasyonu RLS ile DB'ye gömün.** Postgres **Row-Level Security** ile her sorgu otomatik `tenant_id`'ye scope'lansın. İzolasyon, "geliştirici umarım her query'de scope koymuştur" varsayımında değil, veritabanının kendisinde yaşasın. Bu, sızıntıya karşı asıl savunma.
5. **ORM scope'u + indeks/partition ekleyin.** ORM katmanında bir tenant scope koyun (defense-in-depth), sıcak tabloları `tenant_id` ile indeksleyin/partition'layın. Ve bir "whale" tenant büyürse onu kendi DB'sine **promote** etme yolunu baştan açık tutun.

**Sonuç:** Ben olsam shared DB + her yerde `tenant_id` + Postgres RLS kurardım. Backup ve migration shared modelde en basit; güvenlik ödediğiniz bedel ama onu RLS ile geri alıyorsunuz. ORM scope'unu ikinci savunma katmanı yapın, sıcak tabloları `tenant_id` ile partition'layın, dev büyüyen tenant için kendi DB'sine taşıma kapısını açık bırakın. Veri mimarisinin neden böyle kurulduğunu sade.dev'de açıyorum.

## İlgili Yazılar

- [PostgreSQL Her Şeye Yeter mi?](https://sade.dev/tr/journal/postgresql-her-seye-yeter-mi) — sade.dev
- [Zaman serisi verisi için TimescaleDB mi, InfluxDB mu?](https://www.muhammetsafak.com.tr/sor-bakalim/zaman-serisi-verisi-timescaledb-mi-influxdb-mu/) — Sor Bakalım
- [CQRS'i ne zaman uygulamalı ve okuma/yazma modellerini nasıl senkronlamalıyım?](https://www.muhammetsafak.com.tr/sor-bakalim/cqrs-ne-zaman-uygulanir-ve-okuma-yazma-senkronizasyonu/) — Sor Bakalım
- [Esnek ürün nitelikleri için NoSQL mu, PostgreSQL mi seçmeliyim?](https://www.muhammetsafak.com.tr/sor-bakalim/esnek-urun-nitelikleri-icin-nosql-mu-postgresql-mi/) — Sor Bakalım