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

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 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.