Blog Detayi

Her multi-tenant SaaS ürünü er ya da geç aynı soruyla karşılaşır: bir müşterinin verisi diğerinden ne kadar sıkı ayrılmalı? PostgreSQL'de bu karar genellikle iki desene indirgenir — her tabloda bir tenant_id kolonu bulunan paylaşımlı bir şema, ya da aynı veritabanı içinde tenant başına ayrı bir şema. Biz bu yelpazenin her iki ucunda da ürün geliştirdik ve doğru cevap tutarlı bir şekilde hangi desenin daha "moda" olduğuna değil, alanın kendisine bağlı çıktı.

Paylaşımlı Şema: Basit, Ama Sonsuza Kadar Değil

Paylaşımlı şema — tek bir tablo seti, her satırda bir tenant kimliği etiketi — yayına çıkmanın en hızlı yoludur. Migration'lar bir kez çalışır, connection pooling basittir ve tenant'lar arası analitik tek bir sorgu uzaklığındadır. Bu, QTable'ın restoran tenant'ları ve POWER RESEARCH'ün şube bazlı izolasyonunun arkasındaki modeldir: tenant sayısı yüksektir ama her tenant'ın veri ayak izi mütevazıdır ve tek şemanın operasyonel sadeliği, ayırmanın izolasyon faydalarına ağır basar.

Bunun bedeli disiplindir. Her sorgu, her arka plan işi, her rapor bir tenant filtresine ihtiyaç duyar ve eksik bir WHERE tenant_id = ..., beklemede bir veri sızıntısıdır. Row-level security yardımcı olur ama bu, sonradan eklenecek bir şey değil, ilk günden itibaren zorunlu bir gereksinim olarak ele alınmalıdır.

Şema Bazlı Tenant: Bir Özellik Olarak İzolasyon

TradeCheck için tam tersi yönde gittik. Her tenant — bir banka, bir dış ticaret firması — schema_translate_map üzerinden yönlendirilen ve organizasyon başına bir subdomain'e sahip kendi PostgreSQL şemasını alır. Bu, gerçek bir izolasyon satın alır: kötü bir migration veya bir tenant'ın verisindeki bir hata, sessizce bir başkasınınkini bozamaz; yedeklemeler tenant bazında kapsamlandırılabilir ve "bu müşteriye ait her şeyi sil" işlemi, onlarca tablo genelinde filtrelenmiş bir silme yerine tek bir şema üzerinde bir işlemdir. Migration araçları açısından — her şemaya aynı DDL uygulanması gerektiğinden — ve bağlantı yönetimi açısından daha maliyetlidir; ama finansal belgeler işleyen bir ürün için bu takas doğrudur.

Nasıl Karar Veriyoruz

Pratikte karar üç soruya indirgenir: veri tenant'lar arasında sızarsa ne kadar hassas olur, gerçekçi olarak kaç tenant olacak ve tenant başına özelleştirme ne kadar önemli? Yüksek hassasiyet ve düşük tenant sayısı şema bazlı yaklaşıma; yüksek tenant sayısı ve nispeten homojen, düşük riskli veri ise sıkı satır bazlı filtrelemeyle paylaşımlı şemaya iter. İki desen de birbirinden "daha ileri" değildir — farklı sorunları çözerler ve alanınız için yanlış deseni seçmek, birini kötü uygulamaktan çok daha büyük bir risktir.