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.

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