Veritabanı operasyonları “tüm cloud’un en stresli kısmı” olarak bilinir. Backup stratejisi, HA topolojisi, version upgrade, patch yönetimi, performance tuning, security hardening — hepsi 7/24 dikkat ister. Bu yüzden son yıllarda managed database (DBaaS) seçenekleri yaygınlaştı. Ama “her zaman managed” kuralı doğru değil; bazı senaryolarda self-managed hâlâ daha mantıklı. Bu yazıda 4 popüler database için müşterilerimizde nasıl karar verdiğimizi paylaşıyorum.

Managed Database’in Net Faydaları

• Patch ve version upgrade: Otomatik veya tek tıkla. Self-managed’da patch günü stres günü.
• Backup ve PITR: Point-in-time recovery default. Self-managed’da pgBackRest veya WAL-G kurulumu, retention yönetimi.
• HA failover: Master crash → standby otomatik promote. Self-managed’da repmgr / Patroni / orchestrator gibi tooling şart.
• Monitoring: Slow query log, connection pool stats, vacuum stats hazır.
• Security: Encryption-at-rest, TLS-in-transit, audit log, IAM entegrasyonu out-of-box.
• Read replica: 1-2 tıkla.

Managed Database’in Kısıtları

• Superuser yok: Bazı extension’lar (pg_repack, pgaudit özel config) yüklenemez.
• Custom config sınırı: postgresql.conf’ta her parametre değiştirilemez.
• OS-level access yok: SSH veremezsin, troubleshooting bazen zor.
• Maliyet: Self-managed’a göre %30-80 daha pahalı.
• Vendor lock-in: Hyperscaler-specific feature kullanırsan portability gider.

PostgreSQL: En Yaygın, En Kritik Karar

Senaryo	Tavsiye
OLTP web app, <500 GB, RPO=5dk	Managed (Azure Database for PostgreSQL Flexible, AWS RDS, CloudSpark Managed PostgreSQL)
Multi-tenant SaaS, citus extension gerekli	Self-managed (citus desteği managed’da kısıtlı)
Data warehouse, >5 TB, parallel query yoğun	Self-managed (specific tuning gerekli)
Geographic distributed (multi-region active)	Self-managed + Patroni veya Citus
Banka kor banking, custom audit, SOX uyumu	Self-managed (custom config)

Bursa’daki bir SaaS müşterimizin 8 müşteri için ayrı PostgreSQL veritabanları vardı, her biri ~~50 GB. Managed seçtik. Aylık $480/instance × 8 = $3.840. Self-managed yapsak ~~$1.800 + 0.5 FTE DBA ücretiyle aynı seviyeye gelirdi, ama o ekip o hızda kuramaz / yönetemezdi. Karar net.

MySQL: Nicely Managed

MySQL hyperscaler’larda en olgun managed servislerden biri. Özellikler:

• Otomatik backup (default 7 gün, 35 güne çıkarılabilir)
• Read replica (HA için ya da read-heavy workload için)
• InnoDB Cluster opsiyonel (multi-master)
• MySQL HeatWave (analytics workload için in-memory column store)

Self-managed’a tercih sebebi:

• e-commerce app’ler için “%80 use-case” managed yeter
• WordPress / Drupal / Magento gibi standart workload için ideal

Self-managed gerekçesi:

• Çok eski MySQL version (5.6 ve altı, EOL) – managed migrate ister
• Custom storage engine (TokuDB, MyRocks gibi)
• Çok büyük tabular workload (managed’da scale limit’leri var)

MongoDB: MongoDB Atlas Tercih Kazanıyor

MongoDB için en gelişmiş managed deneyim MongoDB Atlas (resmi). Hyperscaler’ların kendi alternatifi (Azure Cosmos DB MongoDB API, AWS DocumentDB) MongoDB API uyumlu ama gerçek MongoDB değil — bazı feature’lar eksik.

Seçenek	Tip	Uyarı
MongoDB Atlas	Vendor managed	Tam MongoDB özellik seti, multi-cloud, en pahalı
Azure Cosmos DB Mongo API	Hyperscaler	Mongo API emülasyonu, bazı eksikler
AWS DocumentDB	Hyperscaler	Aynı, MongoDB değil
Self-managed (replica set)	Müşteri yönetimi	Patroni karşılığı tooling yok, ops yükü yüksek

Müşterimizde önerimiz: MongoDB heavy workload varsa Atlas (CloudSpark’ta hosted MongoDB veya Atlas dedicated cluster). Light workload’da PostgreSQL’in JSONB kolonu ile çoğu MongoDB use-case karşılanıyor (ve daha iyi yönetilebiliyor).

Redis: Cluster Mode + Sentinel

Redis için managed servisler:

• Azure Cache for Redis (Standard, Premium, Enterprise tier’lar)
• AWS ElastiCache
• Redis Enterprise Cloud
• Self-managed Redis Cluster + Sentinel

Karar matrisi:

• Session cache, basit key-value: Managed (Standard tier yeter)
• Pub/Sub, stream, geospatial: Managed Premium veya Enterprise
• RedisJSON, RedisSearch, RedisGraph: Redis Enterprise (modules)
• Çok büyük cluster (100+ shards): Self-managed + custom tooling

Bir e-ticaret müşterimizde session + product catalog cache için CloudSpark Managed Redis (3 node cluster, 6 GB total) kullanıyoruz. Aylık $180. Self-managed yapsak $80 IaaS + saatlerce setup + sürekli izleme. Karar yine managed.

HA Topolojileri: Senaryoya Göre

PostgreSQL primary + standby (Streaming Replication):

┌─────────────────┐         ┌─────────────────┐
│  Primary        │  WAL →  │  Standby        │
│  (read+write)   │         │  (read-only)    │
│  pg-prod-01     │         │  pg-prod-02     │
└─────────────────┘         └─────────────────┘
        │                           │
        └─────── Failover ──────────┘
                  ↓
       Pgpool / HAProxy / pg_auto_failover

RPO <5 sn (asynchronous), RTO ~~30 sn.

MongoDB Replica Set:

Primary ←→ Secondary ←→ Secondary
   │           │            │
   └───── Election ─────────┘ (otomatik failover)

Minimum 3 node (election için). RPO ~~saniyeler, RTO ~~10-30 sn.

Backup Stratejisi: PITR ve Long-term Retention

Backup tipi	Kullanım
Continuous WAL/oplog backup	PITR (point-in-time recovery), son 35 gün
Daily full backup	Restore başlangıç noktası
Weekly full → cold storage	30-90 günlük retention
Monthly snapshot → archive	1-7 yıllık retention (regülasyon)

PITR ile herhangi bir zamana (saniye precision) restore edebilmek için WAL archive sürekli object storage’a gönderiliyor. Müşteri yanlışlıkla 14:23’te DROP TABLE çalıştırırsa, 14:22:30’a restore yapılır, 30 saniyelik veri kaybı.

Version Upgrade: Major Version Geçişleri

PostgreSQL 14 → 15 → 16 gibi major version geçişleri managed’da %95 click-of-button. Self-managed’da pg_upgrade veya logical replication ile downtime yönetimi gerekiyor (saatlerce DBA mesai).

Müşterimizde son 2 yılda 6 farklı PostgreSQL Flexible Server major upgrade yaptık, hepsi 5-10 dakikada bitti, kullanıcı etkisi 30 saniye.

Sahada Düşülen Üç Tuzak

1. Connection pool yok: Application 50 connection açıyor, database 100 connection limit’inde, peak’te boğuluyor. PgBouncer veya RDS Proxy şart.
2. Backup test edilmiyor: Backup var sanıyorsun, restore zamanı dosya bozuk. Quarter’da 1 restore drill.
3. Read replica’ya hot path yazıları gönderme: Read replica replication lag yaşar (bazen 30 sn+), eventual consistency. Stale data tolere edebilen sorgular için.

Sonuç: %80 Managed, %20 Self-Managed

2026’daki tipik kurumsal mimaride veritabanlarının %80’i managed, %20’si self-managed (özel ihtiyaç). Managed’a operasyonel yük azaltma, hızlı kurulum, hazır HA için. Self-managed’a custom config, lisans optimizasyonu, vendor-independence için.

CloudSpark olarak Managed PostgreSQL, MySQL, Redis hizmetleri sunuyoruz. Mevcut self-managed veritabanlarınız için migration assessment ve managed’a geçiş projeleri yürütüyoruz.