# 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://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.

## Kısa cevap

Önce neden diğer ikisini elediğimi söyleyeyim, çünkü karar bu sayıda operasyona bakar. Aynı "veri sınırını nereye koyacağım" sorusunun servis ayırma tarafındaki hâlini [monolitten mikroservise geçiş sorusunda](/tr/sor-bakalim/monolitten-mikroservise-strangler-fig-ile-kademeli-gecis/) tartışmıştım.

## Neden

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ıdır.

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üdür; fakat 10k şemada katalog şişer, migration hâlâ N kere koşar. Birkaç yüz tenant'a kadar iyi, on bine değil.

3. **Shared modelde takas ettiğiniz tek şey güvenliktir.** Tek şema, her tabloda `tenant_id`; backup ve migration en basit burada, maliyet en düşük. Geriye kalan risk sızıntıdır ve onu geri satın almanın bir yolu vardır.

## Ne yapmalı

1. **Shared DB + her yerde `tenant_id` kurun.** Tek şema, tek migration, tek backup. 10.000 tenant için tek instance'ın kaynağını paylaşırsınız.

2. **İzolasyonu RLS ile DB'ye gömün.** Tabloda `ALTER TABLE ... ENABLE ROW LEVEL SECURITY` açıp bir `CREATE POLICY` ile satırları `tenant_id`'ye bağlayın; bundan sonra tabloya her normal erişim o politikadan geçmek zorunda kalır. Politika yazmadan yalnızca RLS'i açmak varsayılan-reddet demektir, yani hiçbir satır görünmez — açmak yetmiyor, politikayı da yazmanız gerekiyor. Bir uyarı: tablo sahibi ve `BYPASSRLS` yetkili roller politikayı atlar; uygulama kullanıcısını tablo sahibi yapmayın, gerekiyorsa `FORCE ROW LEVEL SECURITY` ekleyin. İzolasyon, "geliştirici umarım her query'de scope koymuştur" varsayımında değil, veritabanının kendisinde yaşasın.

3. **ORM scope'u + indeks/partition ekleyin.** ORM katmanında bir tenant scope koyun (defense-in-depth), sıcak tabloları `tenant_id` ile indeksleyin veya partition'layın.

4. **Whale tenant için çıkış kapısını açık bırakın.** Bir müşteri diğerlerini ezecek kadar büyürse onu kendi DB'sine **promote** etme yolunu baştan tasarlayın.

**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://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://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://muhammetsafak.com/tr/sor-bakalim/esnek-urun-nitelikleri-icin-nosql-mu-postgresql-mi/) — Sor Bakalım