Multi-Tenant SaaS Mimarisi: Database, Schema, Row Isolation Stratejileri

AWS SaaS Lens 2025 raporuna göre kurumsal SaaS ürünlerinin %62’si artık hibrit izolasyon modelini benimsiyor; saf “tek model” çözümler yerini tenant tiering stratejilerine bırakıyor. Multi-tenant mimarisi seçimi yalnızca veritabanı kararı değil, regülasyon, maliyet, churn ve yatırım turu değerlemesine dokunan stratejik karardır.

Multi-Tenant SaaS ve 2026 Pazar Gerçeği

Multi-tenancy, tek bir uygulama örneğinin birden çok müşteriye (tenant) hizmet vermesini sağlayan mimari yaklaşımdır. Gartner 2025 SaaS Magic Quadrant raporu, kurumsal SaaS pazarının 2026 sonunda 320 milyar dolara ulaşacağını ve bu pazarın %88’inin multi-tenant temel mimari üzerine kurulu olduğunu raporluyor. Forrester Wave kurumsal alıcıların %71’inin satın alma kararından önce vendor’un izolasyon modelini sorduğunu, %43’ünün ise schema-level veya dedicated DB tercih ettiğini gösteriyor.

Microsoft Multi-tenant SaaS Patterns dokümantasyonu üç ana modelden bahseder: tam pool (shared database, shared schema), bridge (shared database, isolated schema) ve silo (isolated database). Citus Data PostgreSQL benchmark raporu, 50.000 tenant’a kadar pool modelin maliyet açısından öne çıktığını, 50.000 üzeri tenant ile birlikte hibrit gerektiğini gösteriyor. AWS Well-Architected SaaS Lens 2025 sürümü, tenant tier bazlı (free, standard, premium, enterprise) farklı izolasyon stratejileri kullanmayı önermektedir.

Cloud Native Computing Foundation (CNCF) 2025 SaaS Native raporuna göre Kubernetes üzerinde çalışan multi-tenant SaaS sayısı son 18 ayda %184 arttı; bu artışın temel sürükleyicisi tenant başına dedicated namespace ve NetworkPolicy ile sağlanan compute-level izolasyondur. Veritabanı katmanında ise PostgreSQL 16 ile gelen Row-Level Security performans iyileştirmeleri, pool model uygulanabilirliğini 10x ölçeklendirdi. NIST SP 800-204 multi-tenant security pratikleri, izolasyon kararının yalnızca veri katmanında değil network, compute ve secret yönetimi katmanlarında da bütüncül planlanması gerektiğini vurguluyor.

Multi-tenant SaaS mimarisinin temel katmanları aşağıdaki şekilde haritalandırılır:

• Identity ve authentication: Auth0, Cognito veya Keycloak ile tenant-aware JWT yönetimi.
• API gateway routing: Tenant ID’yi subdomain, header veya path’ten alıp upstream’e enjekte etme.
• Application katmanı: Stateless servis instances; tenant context her request’te taşınır.
• Veritabanı katmanı: Pool (RLS), Bridge (schema) veya Silo (DB) izolasyonu.
• Cache katmanı: Redis tenant-prefixed key namespace; cross-tenant cache poisoning engellenir.
• Secret management: AWS Secrets Manager, HashiCorp Vault ile per-tenant encryption key (BYOK).

Üç İzolasyon Modelinin Teknik Karşılaştırması

Pool modelde tüm tenant’lar aynı tablo şemasını paylaşır ve `tenant_id` sütunu ile veriler ayrılır; PostgreSQL Row-Level Security (RLS) politikaları zorunludur. Bridge modelde her tenant’a ayrı bir PostgreSQL schema atanır; aynı veritabanı içinde yüzlerce schema barındırılır. Silo modelde her tenant kendi veritabanına (bazen kendi compute kaynağına) sahiptir; en güçlü izolasyon, en yüksek maliyet.

Karşılaştırma: Tenant Tier ve Doğru Model Eşleşmesi

Modern SaaS ürünleri tek bir izolasyon modeline takılmaz; tenant tier’a göre farklı stratejiler uygular. Bu yaklaşım “tiered isolation” veya “polyglot tenancy” olarak adlandırılır. Tenant değer artışı ile birlikte izolasyon kalitesi de yükselir; bu hem maliyet optimizasyonu hem de premium fiyatlandırma için kaldıraç oluşturur.

• Free / trial tier: Pool model, RLS politikası, rate limit 50 req/dk; tenant başına 0,40 USD/ay maliyet.
• Standard tier: Pool model, RLS + tenant başına connection limit, rate limit 200 req/dk; ortalama 1,80 USD/ay.
• Premium tier: Bridge model, schema-per-tenant, dedicated read replica opsiyonu; 8-15 USD/ay.
• Enterprise tier: Silo model, dedicated PostgreSQL veya RDS instance, VPC peering, bağımsız backup zinciri; 80-400 USD/ay.
• Regülasyon hassas (sağlık, finans): Silo zorunlu, on-premise opsiyonu veya BYOK (bring your own key) encryption ile birlikte gelir.

İlgili konu: PostgreSQL performans optimizasyonu rehberimizde connection pooling, indeks stratejisi ve VACUUM yönetimini detaylandırdık.

Implementation Pattern: PostgreSQL Row-Level Security ile Pool Model

PostgreSQL Row-Level Security (RLS), pool modelin temel taşıdır. Her sorguda `current_setting(‘app.tenant_id’)` değerine göre tenant satırları filtrelenir. Uygulama katmanı her connection açıldığında `SET app.tenant_id = ‘…’` çağrısı yapar; eğer bu çağrı unutulursa cross-tenant veri sızıntısı kaçınılmazdır. Bu nedenle ORM seviyesinde middleware (Sequelize, Prisma, SQLAlchemy) ile zorlamalı injection uygulanır.

Citus Data ve PostgreSQL multi-tenancy benchmark raporu, RLS ile çalışan pool modelin tenant başına ortalama 3,2 milisaniye ek sorgu maliyeti getirdiğini ölçüyor. Connection pooler olarak PgBouncer’ın `transaction` mode’unda RLS değişkeni her transaction başında set edilmelidir; `session` mode’da connection yeniden kullanıldığında stale tenant_id sızıntısı meydana gelir. Üretim ortamında ortalama bir orta-ölçek SaaS, 25 PgBouncer pool ile 1.500 tenant’ı 200 connection üzerinden servis eder.

Bridge modelin implementasyonunda her tenant için ayrı PostgreSQL schema açılır ve search_path tenant geçişinde dinamik olarak güncellenir. SET search_path TO tenant_42, public; komutu connection state’i değiştirir, bu nedenle PgBouncer transaction mode’da her transaction başında yeniden çalıştırılması zorunludur. Schema migration için Flyway veya Liquibase kullanılır; ancak bu araçlar tek-veritabanı odaklı tasarlandığı için multi-schema iterasyon için custom wrapper script gerekir. Üretimde 5.000 schema üzerinde ALTER TABLE ADD COLUMN çalıştırmak 45-90 dakika sürer; CONCURRENTLY veya pg_repack tabanlı progressive migration pattern’i tercih edilir. Silo modelde ise her tenant kendi RDS Instance veya Aurora Serverless v2 cluster’ına sahiptir; tenant onboarding sürecinde Terraform veya AWS CDK ile dakikalar içinde dedicated infrastructure provision edilir.

Operasyon: Migration, Backup, Observability

Multi-tenant operasyonda en sık karşılaşılan üç problem migration, tenant-aware monitoring ve noisy neighbor yönetimidir. Pool modelde schema migration tek tabloya uygulanır ve milyonlarca satırı etkileyebilir; downtime’sız migration için pt-online-schema-change benzeri araçlar veya PostgreSQL’in `ALTER TABLE … ADD COLUMN … DEFAULT NULL` kalıbı kullanılır. Bridge modelde her schema için ayrı migration script’i çalıştırılır; 5.000 schema için tek bir kolon ekleme 45 dakikadan uzun sürebilir.

Sektörel Use Case’ler ve Regülasyon Yansımaları

Slack, Salesforce ve HubSpot pool model üzerine kurulmuştur; tenant başına saniyede yüzbinlerce mesajı düşük maliyetle işlerler. Atlassian Jira Cloud bridge modele 2018’de geçti; her organizasyon için ayrı schema tutar. Workday ve ServiceNow enterprise müşterilerin çoğunluğuna silo model sunar; HIPAA, SOC 2 Type II ve FedRAMP gibi sertifikalar için fiziksel izolasyon kaçınılmazdır. Türkiye pazarında Logo Yazılım, Mikro ve Netsis benzeri ERP SaaS’ları çoğunlukla bridge modelde çalışır; KVKK uyumluluğu schema bazlı izolasyon ile karşılanır.

Finansal hizmetler sektöründe BDDK ve SPK regülasyonları çoğunlukla silo modeli zorunlu kılar. Sağlık SaaS’larında HBYS (Hastane Bilgi Yönetim Sistemleri) verisi Sağlık Bakanlığı ESYS standartlarına göre veri segregasyonu gerektirir. Eğitim teknolojisi (Kahoot, Quizizz, Sınavhane gibi) pool model ile çalışıp tenant tier’a göre upgrade yapar.

Türkiye SaaS ekosisteminde 2024-2025 döneminde Insider, Useinsider, Hubilo ve Atlas.so gibi globalleşen şirketler bridge modelden silo’ya doğru kısmi geçiş yaptı; bu geçişin temel motivasyonu kurumsal anlaşmalardaki BYOK (bring your own key) ve data residency talepleridir. Yerel ERP segmentinde Mikrogen ve Wolvox bridge model üzerinde çalışırken, Akinsoft ve Logo Wings müşteri tabanını tenant tier ile farklı izolasyon modellerine ayırıyor. Eğitim tarafında Sebit, Vitamin ve Eğitim Bilişim Ağı (EBA) gibi platformlar tenant başına bağımsız RDS instance kullanan silo modeli benimsemiş durumda; KVKK’nın çocuk verisi koruması özel hükmü bu kararı zorunlu kılıyor.

İlgili konu: SaaS mimarisi tasarım rehberimizde ölçeklenebilir tenant yönetimi pattern’lerini, KVKK uyumluluk teknik gereksinimleri yazımızda ise veri lokasyon ve şifreleme kurallarını anlattık. Connection pooling ve PgBouncer rehberimiz de pool modelde sık sorulan sorulara odaklanır.

Dış otorite kaynaklar olarak AWS SaaS Factory whitepaper’ları, Microsoft Multi-tenant SaaS patterns, Citus Data PostgreSQL bloğu ve PostgreSQL Row-Level Security dokümantasyonu başvurulması gereken referanslardır.

Kurumsal Multi-Tenant SaaS Dönüşümünde Karşılaşılan Tipik Sorunlar

Danışmanlık projelerinde gözlemlenen tipik darboğazlar:

• Connection pool exhaustion: 1.000 tenant ve 50 connection per tenant ile teorik 50.000 connection ihtiyacı doğar; PgBouncer ve uygulama katmanı limit haritalanmazsa üretimde “too many connections” hatası kaçınılmazdır.
• RLS politikası eksikliği: Yeni eklenen tablolarda RLS politikası unutulduğunda cross-tenant sorguları sessizce çalışır; veri sızıntısı için CI/CD pipeline’da pg_policy denetimi zorunlu olmalı.
• Schema migration süreleri: Bridge modelde 5.000 schema üzerinde ALTER TABLE çalıştırmak 90 dakikayı aşabilir; rolling deployment veya feature flag stratejisi gerekir.
• Tenant offboarding ve veri silme: Tenant kaldırıldığında ilişkili 40-60 tabloda CASCADE DELETE çalıştırmak büyük dataset’lerde 30 dakika sürer; KVKK 30 günlük silme zorunluluğu için scheduled job altyapısı gerekir.
• Cross-tenant audit log: Her tabloya `tenant_id` eklemek yetmez; uygulama-level audit (kim, ne zaman, hangi tenant adına işlem yaptı) için ayrı bir audit_log tablosu kurulmalı.
• Tenant tier upgrade migration: Standard pool’dan premium bridge’e geçiş tenant verisinin yeni schema’ya taşınmasını gerektirir; logical replication ile downtime’sız taşıma için 4-8 hafta planlanmalıdır.

Sonuç

Multi-tenant izolasyon kararı, SaaS ürününüzde geri dönüşü en pahalı tek mimari karardır. Erken aşama ürünlerde pool model en hızlı pazara çıkış yolunu sunar; ancak büyüme ile birlikte regülasyon, premium fiyatlandırma ve müşteri beklentileri bridge veya silo’ya doğru iter. 2026’da en başarılı SaaS şirketleri tek bir modele bağlı kalmıyor; tenant tier’a göre üç modeli birlikte işletiyor. Doğru karar için önce tenant segmentasyonu, fiyatlandırma stratejisi ve hedef regülasyonlar netleştirilmeli, ardından RLS, schema veya silo seçimi yapılmalıdır. PostgreSQL 16+ ile RLS performans iyileştirmeleri ve logical replication olgunluğu, hibrit modelleri her zamankinden daha pratik hale getirdi. Hangi izolasyon stratejisini hangi tenant tier’ında kullandığınızı yorumlarda paylaşmanızı bekliyorum.

Sıkça Sorulan Sorular