Multi-tenant bir SaaS uygulamasında veri izolasyonunu nasıl tasarlarsınız? Paylaşılan tablo, şema başına tenant ve veritabanı başına tenant yaklaşımlarını karşılaştırın.

Multi-tenant SaaS'ta birden fazla müşteri (tenant) aynı uygulamayı kullanır ve temel gereksinim bir tenant'ın asla diğerinin verisini görmemesidir. Üç ana model vardır; çoğu ürün paylaşılan tablo ile başlar, büyük kurumsal müşteriler için izole seçenek sunar.

Paylaşılan tablo modelinde güvenlik

En büyük risk bir sorguda WHERE tenant_id = ? filtresinin unutulmasıdır. Bunu insan disiplinine bırakmayın:

• Repository/ORM katmanında zorunlu tenant filtresi (Prisma extension, Hibernate filter).
• PostgreSQL Row Level Security: filtre veritabanı seviyesinde zorunlu olur.

ALTER TABLE projects ENABLE ROW LEVEL SECURITY;
CREATE POLICY tenant_isolation ON projects
  USING (tenant_id = current_setting('app.tenant_id')::uuid);
-- Her istekte transaction başında:
-- SET LOCAL app.tenant_id = '...';

• Dikkat: tablo sahibi (owner) ve superuser rolleri RLS'i varsayılan olarak atlar. Uygulama owner rolüyle bağlanıyorsa ALTER TABLE projects FORCE ROW LEVEL SECURITY kullanın veya uygulamaya ayrı, ayrıcalıksız bir rol verin.
• Tüm index'ler tenant_id ile başlamalı: (tenant_id, created_at).
• Benzersizlik kısıtları tenant'a göre olmalı: UNIQUE (tenant_id, slug).

Tenant'ın belirlenmesi

• Alt alan adı (acme.app.com), özel alan adı veya token içindeki tenant_id claim'i.
• Kullanıcı birden fazla tenant'a üye olabiliyorsa memberships(user_id, tenant_id, role) tablosu ve tenant seçici UI gerekir.

Diğer konular

• Noisy neighbor: bir tenant'ın yoğun kullanımı diğerlerini yavaşlatmasın; tenant bazlı rate limit ve kota.
• Cache anahtarları tenant içermeli: tenant:{id}:dashboard. Aksi halde veri sızar.
• Arka plan job'ları ve loglar tenant bağlamını taşımalı.
• Faturalama ve plan limitleri (kullanıcı sayısı, depolama) tenant seviyesinde uygulanır.
• Veri silme / dışa aktarma: KVKK/GDPR talepleri için bir tenant'ın tüm verisi kolayca bulunabilmeli.