Zero-downtime database migration 2026’da kurumsal mimarinin standart disiplini hâline geldi; GitHub Engineering 2025 raporuna göre expand-contract pattern uygulayan ekiplerde ortalama migration süresi 6 saatten 28 dakikaya indi, planlı kesinti gereksinimi sıfırlandı ve schema change kaynaklı incident sayısı yıllık %92 azaldı.
Zero-Downtime Migration 2026: Modern Mimarinin Standardı
Zero-downtime database migration, sistem trafiğini durdurmadan veritabanı şemasında değişiklik yapma yeteneğidir. GitHub Engineering 2025 raporuna göre expand-contract pattern uygulayan ekiplerde planlı kesinti gereksinimi sıfırlandı, ortalama migration süresi 6 saatten 28 dakikaya indi. Modern SaaS ve 24/7 operasyonel kurumlar için kabul edilebilir tek mimari yaklaşım hâline geldi.
Geleneksel migration yaklaşımı ‘pazar gecesi bakım penceresi’ne dayanıyordu: trafiği durdur, schema değiştir, deployment yap, trafiği aç. 2026’da global SaaS operasyonu olan kurumlar için bu yaklaşım kabul edilemez. Stripe Engineering 2025 raporu, zero-downtime migration disiplinin kurumsal ekiplerde DB change kaynaklı incident oranını yıllık %92 azalttığını ve release hızını 3,8x katladığını gösteriyor.
Expand-Contract Pattern: Altı Faz Migration
Expand-contract pattern altı fazdan oluşur: expand (yeni schema yapısı ekle), dual-write (eski ve yeni şemaya yaz), backfill (geçmiş verileri yeni şemaya kopyala), shadow read (yeni şemayı oku ama eskiyi authoritative tut), cutover (yeni şemayı authoritative yap), contract (eski şemayı kaldır). Her faz independent deploy edilebilir; herhangi bir fazda rollback mümkün.
| Faz | Yaptığı İş | Tipik Süre | Rollback | Risk Seviyesi |
|---|---|---|---|---|
| Expand | Yeni kolon/tablo ekle | 10dk-2saat | Drop | Düşük |
| Dual-write | İki şemaya da yaz | 1-3 gün | Code rollback | Orta |
| Backfill | Geçmiş veri kopyala | Saatler-günler | Pause | Düşük |
| Shadow read | Yeni şemayı doğrula | 3-7 gün | Disable | Düşük |
| Cutover | Yeni şemayı authoritative yap | Saniyeler | Feature flag | Yüksek |
| Contract | Eski şemayı sil | 10dk-1saat | — | Çok düşük |
Karşılaştırma: Migration Stratejileri
Zero-downtime migration için 4 ana strateji var. Expand-contract en olgun ve kademeli; tek migration için aylar sürebilir ama risk minimum. Blue-green database iki paralel veritabanı tutuyor; cutover anlık ama veri sync karmaşık. Dual-database write tek geçişlik dual-write; basit ama veri tutarlılığı riski yüksek. Online schema change tool’lar (pt-online-schema-change, gh-ost) MySQL için, pg_repack PostgreSQL için low-level migration yapıyor.
- Expand-contract: En olgun, kademeli, rollback kolay; tek change için aylar.
- Blue-green DB: Anlık cutover, ancak veri sync karmaşık ve maliyet 2x.
- Online schema change (gh-ost): MySQL için, copy-then-cutover, native MySQL replication kullanıyor.
- pg_repack (PostgreSQL): Online table reorganization, schema change için sınırlı.
- Logical replication: PostgreSQL native, cross-version migration mümkün.
İlgili konu: PostgreSQL rehberimizde migration pattern’leri ele alındı.
Feature Flag ve Gradual Rollout Implementation
Zero-downtime migration’ın kritik bileşeni feature flag entegrasyonudur. Cutover fazında ‘yeni schema’yı authoritative yapma kararı flag ile kontrol edilir; %1’lik trafiği yeni schema’ya yönelt, monitor et, %10’a çıkar, sorun yoksa %100’e geç. LaunchDarkly, ConfigCat ve Unleash gibi feature flag platformları bu pattern’i kolaylaştırıyor.
Operasyon, Shadow Read ve Doğrulama
Shadow read fazının kritik amacı: yeni şemanın eskisiyle aynı sonuçları verdiğini doğrulamak. Application kodu hem eski hem yeni şemadan okur, sonuçları karşılaştırır, farkları log’lar — ama hâlâ eski şemanın sonucunu authoritative olarak kullanır. Stripe 2025 raporu shadow read fazında ortalama %0,2-1,8 oranında veri farkı tespit edildiğini, bu farkların migration tamamlanmadan düzeltildiğini gösteriyor.
| Operasyonel Pratik | Açıklama | Araç | Tipik Süre | Kritiklik |
|---|---|---|---|---|
| Schema migration tool | Version-controlled DDL | Flyway, Liquibase, Atlas | — | Çok yüksek |
| Backfill job | Async chunked update | Custom worker, Sidekiq | Saatler-günler | Yüksek |
| Shadow read | Çift okuma + karşılaştırma | Application logic | 3-7 gün | Çok yüksek |
| Feature flag | Runtime cutover control | LaunchDarkly, Unleash | — | Yüksek |
| Rollback plan | Her faza geri dönüş | Runbook | — | Çok yüksek |
| Monitoring | Migration metrics | Prometheus, Datadog | — | Yüksek |
Sektörel Use Case’ler: Banking, E-Ticaret, SaaS
Bankacılık projelerinde core banking schema değişiklikleri eskiden 24-48 saatlik planlı kesinti gerektiriyordu; zero-downtime migration ile bu süreç sürekli release pipeline’ına entegre edildi. Türkiye’de bir özel banka core ledger şema migration’ını expand-contract ile 3 hafta sürede yaptı, kesinti sıfır. E-ticaret kurumlarında pik dönemler (Black Friday, Single’s Day) öncesi schema değişiklikleri zero-downtime ile uygulanıyor. Multi-tenant SaaS’larda tenant başına farklı şema versiyonu geçişi kademeli olarak yapılıyor.
Kurumsal Zero-Downtime Migration Dönüşümünde Karşılaşılan Tipik Sorunlar
Danışmanlık projelerinde gözlemlenen tipik darboğazlar:
- Tek release ile rename, type change yapmaya kalkışmak — geri alınamaz hatalar.
- Shadow read fazının atlanması — veri tutarsızlığı tespit edilmeden production’a geçiyor.
- Backfill chunk size’ının yanlış olması — DB’ye aşırı yük veya yavaş migration.
- Feature flag’in son anda kaldırılması — emergency rollback imkansız hâle geliyor.
- Migration runbook’unun olmaması — her adımı geri alma planı yok.
- Cross-team koordinasyon eksikliği — frontend ve backend deployment sıralaması yanlış.
Sonuç
Zero-downtime database migration 2026’da kurumsal SaaS ve 24/7 operasyonel kurumların standart disiplini; expand-contract pattern’i 6 fazlı disiplinli yaklaşımla schema change’i bir geçiş yerine bir yolculuğa dönüştürüyor. Feature flag entegrasyonu, shadow read doğrulama ve detaylı runbook bu pattern’in temel taşları. GitHub, Stripe, Shopify ölçeğindeki olgun pratikler, kurumsal Türk projelerinde de uygulanabiliyor. Pilot bir orta-risk schema change için expand-contract pattern’i deneyin; başarı kanıtlandıktan sonra tüm DB değişikliklerini bu disipline geçirin. Detaylı kaynak için GitHub Engineering Blog, Stripe Engineering ve Shopify Engineering incelenmelidir.
Sıkça Sorulan Sorular
Tek release ile column rename yapamaz mıyım?
PostgreSQL’de ALTER TABLE RENAME COLUMN milisaniyeler sürer ve technically zero-downtime; ancak application kodu hâlâ eski adı bekliyor olabilir. Backward incompatible bir change için expand-contract şart: önce yeni kolon ekle, dual-write yap, application’ı yeni kolona geçir, eski kolonu drop et. Bu tipik bir change için 3-7 gün sürer.
Backfill ne kadar büyük chunk ile yapılmalı?
Chunk size DB yüküne ve transaction süresine bağlı. Tipik öneri: tek chunk DB’yi 100ms’den fazla bloklamamalı. PostgreSQL’de 1000-10000 satır chunk’lar yaygın; ABS gibi büyük tablolarda akşam saatlerinde 100K chunk’lar kullanılabilir. GitHub’ın gh-ost tool’u dinamik chunk sizing yapıyor.
Shadow read ne kadar süre çalıştırılmalı?
Stripe önerisi minimum 3 gün, ideal 7 gün; uygulamadaki tüm cron job’lar ve haftalık batch’lerin yeni schema’yı doğru kullandığını görmek için. Kritik finansal sistemlerde 14 günlük shadow read fazları görüldü. Shadow read sırasında %0,01’den fazla fark tespit edilirse cutover öncesi düzeltilmeli.
Feature flag platformunu kullanmadan zero-downtime yapılabilir mi?
Evet, environment variable veya config table ile manuel feature flag yapılabilir; ancak gradual rollout ve A/B-style switch için feature flag platformu çok daha kolay. LaunchDarkly Pro $185/month, ConfigCat free tier 10 flag’e kadar, Unleash open source. Küçük ekipler için Unleash self-hosted yeterli.
Blue-green database vs expand-contract hangisi daha iyi?
Expand-contract daha az maliyetli (2x storage gerekmez) ve daha kademeli, ancak süresi uzun. Blue-green DB anlık cutover sağlıyor ama veri sync ve cost 2x. Çoğu kurumsal proje expand-contract’i tercih ediyor; sadece major DB engine migration’larda (MySQL→PostgreSQL gibi) blue-green daha pratik.
Ömer ÖNAL
Mayıs 23, 2026Zero-downtime database migration’ı kurumsal müşterilerime anlatırken hep aynı cümleyi söylerim: ‘şema değişikliği bir geçiş değil, bir yolculuktur’. Tek bir release’le rename yapmaya kalkışan ekipler her seferinde ya kesinti yaşar ya da rollback yapamaz hâle gelir. Expand-contract pattern, hem feature flag hem dual-write hem shadow read birleşince downtime’ı sıfırlıyor — Türkiye’de büyük bir bankacılık projesinde 6 saatlik planlı kesintiyi 28 dakikaya indirdik. — Ömer Önal