SaaS Multi-Tenant Database 2026 yılında row, schema ve database-per-tenant pattern’lerinin karar matrisi netleşti. Gartner 2025 SaaS Market Report, küresel SaaS pazarının 295 milyar dolara ulaştığını gösteriyor. AWS SaaS Factory 2025: multi-tenant DB mimarisi seçiminin sonradan değişimi projelerin %42’sinde 12+ ay ek yatırım gerektiriyor. Konuyla ilişkili olarak Zero-Downtime Database Migration 2026: Expand-Contract Pattern rehberimiz detaylı incelemeyi içerir. Konuyla ilişkili olarak Atlas vs Liquibase vs Flyway 2026: Database Migration Production Karşılaştırma rehberimiz detaylı incelemeyi içerir.
SaaS Multi-Tenancy: 2026 Mimari Bağlamı
Multi-tenancy, tek bir SaaS instance’ın birden fazla müşteriye (tenant) hizmet vermesi modelidir. Veri tabanı katmanında 3 ana izolasyon pattern: shared database/shared schema (row-level), shared database/separate schema, database-per-tenant. Her birinin maliyet, izolasyon, scalability, compliance trade-off’u farklı. Forrester 2025 SaaS Wave: yeni SaaS startup’ların %78’i row-level başlıyor; enterprise pivot’unda hibrit tier-based yapı yaygın.
Statista 2025: küresel SaaS abonelikleri Fortune 500 başına ortalama 247 uygulama; tenant izolasyon hatası en yaygın enterprise satış engellerinden biri. SOC 2 Type II ve ISO 27001 audit’leri tenant data isolation kontrolünü açıkça denetliyor. IBM Cost of a Data Breach 2025: SaaS tenant data leak’inde ortalama maliyet 5,17 milyon dolar.
Row-Level Tenancy: Shared Database Pattern
Row-level tenancy, tüm tenant verilerinin aynı tablo’da tenant_id kolonu ile ayrıştırıldığı pattern. En basit, en ucuz, en yaygın başlangıç. PostgreSQL Row Level Security (RLS) ile uygulama-bağımsız policy zorlama mümkün. Her tablo için RLS policy: USING (tenant_id = current_setting(‘app.current_tenant’)::uuid).
| Pattern | İzolasyon | Cost Per Tenant | Noisy Neighbor | Migration |
|---|---|---|---|---|
| Row-Level | Düşük (RLS ile orta) | En düşük | Yüksek risk | Toplu migration |
| Schema-Level | Orta | Orta | Orta risk | Schema başına |
| Database-Per-Tenant | Yüksek | En yüksek | Yok | Tenant başına |
| Hybrid Tier-Based | Tier’a göre | Optimal | Premium’da yok | Tier başına |
| Sharded Multi-Tenant | Shard’a göre | Orta | Shard içi | Re-shard zor |
Schema-Level Tenancy: PostgreSQL Schema Pattern
Schema-level tenancy, her tenant için aynı database içinde ayrı schema (PostgreSQL search_path) tanımlanmasıdır. SQL Server’da database role; MySQL’de ayrı database (MySQL schema = database). İzolasyon row-level’dan güçlü, database-per-tenant’tan ucuz. Migration tenant başına yürütülüyor; schema sayısı PostgreSQL’de 65.000+ desteklenir ama operasyonel olarak 1.000-5.000 tipik üst limit.
Database-Per-Tenant: Maximum İzolasyon
Her tenant için ayrı database instance veya logical database. AWS RDS, Aurora veya CloudSQL üzerinde tenant başına 1 instance. İzolasyon en yüksek; compliance ve regülasyon ağırlıklı senaryolarda (HIPAA, finance, government) tercih. Cost overhead yüksek; tenant başına minimum $40-100/ay alt limit. Workday, Salesforce premium tier’larında bu pattern.
Hibrit Tier-Based: 2026 En Yaygın Pattern
Gerçek dünyada saf bir pattern nadir; çoğu olgun SaaS hibrit yaklaşım kullanır. Free/Starter tier: row-level; Pro/Team tier: schema-level; Enterprise tier: database-per-tenant. SaaS revenue tier’ı ile mimari maliyet eşleşir. Atlassian Cloud, Notion, Slack bu modeli uyguluyor; Salesforce kendi multi-tenant platform’unda hibrit pattern.
- Free Tier: Row-level, RLS, çok düşük kaynak limit
- Pro Tier: Schema-level (PostgreSQL schema veya MySQL database)
- Enterprise: Dedicated database, AZ-redundant
- Premium: Region-specific deploy (data residency)
- Government: Air-gapped on-premise opsiyon
İlgili konu: PostgreSQL performance tuning rehberimizde multi-tenant özelinde index ve connection pool stratejisini detaylandırdık.
PostgreSQL Row Level Security: Production Implementation
PostgreSQL RLS, PostgreSQL 9.5+’tan beri stable. tenant_id’yi session variable (SET app.current_tenant = ‘uuid-…’) olarak tutarsınız; tablo policy’leri bu değeri okur. Her tablo için 4 policy: SELECT, INSERT, UPDATE, DELETE. Implementation karmaşık ama uygulama-bağımsız izolasyon zorlama sağlıyor; uygulama developer hatasıyla cross-tenant data exposure önleniyor.
Noisy Neighbor Problemi ve Çözümleri
Multi-tenant’ın en yaygın production sorunu noisy neighbor: bir tenant’ın yoğun query’leri diğer tenant’ları yavaşlatıyor. Çözümler: PostgreSQL pg_cgroups, connection pool tenant başına limit, slow query alerting, premium tenant’ları dedicated database’e taşıma. AWS Aurora Serverless v2 elastic scaling sorunun bir kısmını absorbe ediyor.
| Çözüm | Yaklaşım | Etki |
|---|---|---|
| Connection Pool Limit | Tenant başına max conn | Connection exhaustion önleme |
| Query Timeout | SET statement_timeout | Long-running query block |
| Slow Query Alert | pg_stat_statements | Erken tespit |
| Resource Limit (Aurora Serverless) | ACU autoscale | Elastic absorb |
| Dedicated DB (Premium tier) | Tier’a göre izolasyon | Tam çözüm, maliyet yüksek |
Tenant Onboarding ve Migration Otomasyonu
Yeni tenant onboarding 30 saniye altında olmalı. Row-level’da yeni tenant_id INSERT yeterli; schema-level’da yeni schema oluştur + migration yürüt; database-per-tenant’ta provision + migration. Liquibase, Flyway, Atlas gibi tool’lar tenant-aware migration sağlıyor. Tenant başına migration runtime production’da dakikalar; 1.000+ tenant’ta job orchestration (Argo Workflows, Temporal) gerekiyor.
Sektörel Use Case: B2B SaaS, Fintech, Healthcare
B2B SaaS’te tier-based hibrit en yaygın (Notion, Linear, Vercel). Fintech’te regülasyon ağırlıklı tenant’lar için dedicated database (Plaid, Mercury). Healthcare’de HIPAA compliance için per-tenant database ve audit log isolation zorunlu. Government’ta data residency için region-specific deploy.
Kurumsal Multi-Tenant Database Dönüşümünde Karşılaşılan Tipik Sorunlar
Danışmanlık projelerinde gözlemlenen tipik darboğazlar:
- Pattern seçimini sadece “tenant sayısı” ile yapma — compliance, noisy neighbor, migration gözden kaçıyor
- Row-level RLS yerine application-side tenant filter — developer hatasıyla cross-tenant leak
- Migration scripti tenant başına idempotent değil — partial failure’da inconsistent state
- Connection pool tenant-aware değil — bir tenant connection’ları tüketiyor
- Backup ve restore strategy’sinin tenant başına olmaması — bir tenant veri kaybında tüm backup restore
- Audit log isolation eksikliği — tenant başına audit raporu üretilemiyor
Sonuç
Multi-tenant database mimarisi 2026’da SaaS başarısının kritik kararı. Başlangıç için row-level + RLS hızlı ama 1.000+ tenant’ta noisy neighbor kaçınılmaz. Tier-based hibrit (free row-level, enterprise dedicated DB) gelir tier ile mimari maliyet eşleşmesi sağlıyor. Pattern değişikliği 12+ ay’lık migration projesi; ilk gün doğru karar verin. Compliance (HIPAA, SOC 2, ISO 27001), data residency, noisy neighbor risk profili 3 ana karar değişkeni.
Sıkça Sorulan Sorular
Row-level RLS performance’ı ne kadar etkiler?
Doğru index’lenmişse minimal (<%5 query latency). tenant_id her tabloda composite index'in ilk kolonu olmalı. Yanlış index ile %50+ slowdown mümkün. PostgreSQL EXPLAIN ANALYZE ile RLS policy execution plan'da görülür.
1.000+ schema PostgreSQL’de yönetilebilir mi?
Teknik olarak evet (max 65.000), operasyonel olarak 5.000+ schema migration zaman alıcı. AWS Aurora ve Google CloudSQL bu ölçeği desteklemekle birlikte connection pool ve search_path management overhead artar.
Database-per-tenant cost-prohibitive mi?
AWS RDS Aurora Serverless v2 ile minimum tenant başına $8-15/ay’a düşürülebiliyor (auto-scale to zero). Tier başına analiz: $50+/ay tenant pricing varsa dedicated database ROI pozitif; $5/ay free tier’da shared schema zorunlu.
Cross-tenant query (analytics) nasıl yapılır?
Row-level’da kolay (SUPERUSER role veya RLS bypass). Schema/database-level’da CDC (Debezium) ile data warehouse (Snowflake, BigQuery) consolidate edilir; analytics warehouse’da query. Operational + analytical workload ayrışması best practice.
Türkiye’de KVKK için data residency nasıl yönetilir?
Yurt içinde fiziksel veri saklama isteyen müşteriler için Türkiye region (AWS İstanbul, Azure North Europe + İstanbul Edge) deploy gerekir. Multi-region SaaS mimarisi tenant başına region routing ile sağlanır; database-per-tenant veya regional schema pattern’i tercih edilir.
Ömer ÖNAL
Mayıs 23, 2026Multi-tenant DB pattern seçimini sadece ‘tenant sayısı’ ile yapan ekipler 18 ay sonra noisy neighbor veya migration overhead duvarına çarpıyor. Doğru karar matrisi: tenant başına row count + isolation requirement + compliance (HIPAA/GDPR) + cost model. PostgreSQL Row Level Security olgun ama tablo başına 10M+ satırda performans cezası gerçek. Hibrit pattern (premium tenant’lar dedicated DB, free tier shared schema) en yaygın. — Ömer Önal