Veritabanı Migrasyon ve Versiyon Yönetimi Rehberi [2026]

Veritabanı Şemanız Kod Kadar Yönetilmiyor mu?

Birçok ekip uygulama kodunu Git ile titizlikle versiyonlar, code review süreçlerinden geçirir, CI/CD pipeline ile dağıtır. Ancak aynı ekipler veritabanı değişikliklerini hala elle SQL çalıştırarak, DBA'ya Slack mesajı atarak veya production sunucusuna SSH ile bağlanarak yapar. Sonuç tahmin edilebilir: hangi şema değişikliğinin ne zaman yapıldığı belirsizdir, geri alma imkansızdır, ortamlar arası tutarsızlık kaçınılmazdır.

Veritabanı migrasyon yönetimi bu sorunu kökünden çözer. Şema değişikliklerini versiyonlanmış, tekrarlanabilir ve otomatik hale getirir. Bu yazıda migrasyon araçlarından sıfır kesinti stratejilerine, büyük tablo migrasyonlarından CI/CD entegrasyonuna kadar her boyutu ele alıyoruz.

Veritabanı Migrasyonu Nedir ve Neden Gerekli?

Veritabanı migrasyonu, şema yapısındaki değişikliklerin (tablo oluşturma, kolon ekleme, indeks değiştirme, veri dönüştürme) kontrollü ve sıralı biçimde uygulanması sürecidir. Her migrasyon dosyası bir versiyon numarası taşır ve veritabanının mevcut durumunu bir sonraki duruma taşır.

Migrasyon yönetimi olmadan karşılaşılan tipik sorunlar oldukça ciddidir:

• Ortam tutarsızlığı: Geliştirme, staging ve production veritabanları birbirinden farklı şemalara sahip olur. Bir geliştirici yerel ortamda çalışan bir sorguyu staging ortamına taşıdığında tablo yapısının farklı olduğunu keşfeder.
• Geri alma zorluğu: Hatalı bir değişiklik yapıldığında önceki duruma dönmek el yordamıyla yapılır. Bu süreçte veri kaybı riski yüksektir ve stresli bir operasyona dönüşür.
• Ekip koordinasyonu: Birden fazla geliştirici aynı anda şema değişikliği yaptığında çakışmalar tespit edilemez. İki geliştirici aynı tabloya farklı kolonlar eklediğinde merge çakışması yaşanır.
• Denetim eksikliği: Hangi değişikliğin kim tarafından, ne zaman ve neden yapıldığına dair kayıt tutulmaz. Bir sorun yaşandığında kök neden analizi yapılamaz.
• Tekrarlanabilirlik: Yeni bir ortam kurarken şemanın sıfırdan doğru oluşturulması garanti edilemez. Yeni bir geliştirici ekibe katıldığında yerel ortamı kurmak saatler sürer.

Migrasyon araçları bu sorunların tamamını çözer: her değişiklik bir dosyada saklanır, sırası bellidir, otomatik uygulanır ve gerektiğinde geri alınabilir.

Migrasyon Araçları Karşılaştırması

Doğru araç seçimi, teknoloji yığınına ve ekip yapısına bağlıdır. Aşağıdaki tablo yaygın kullanılan migrasyon araçlarını karşılaştırır:

Araç	Dil/Ekosistem	Format	Rollback	Durum Takibi	Öne Çıkan Özellik
Flyway	Java/JVM	SQL, Java	Sınırlı (Pro)	Metadata tablosu	Basitlik, SQL odaklı
Liquibase	Java/JVM	XML, YAML, JSON, SQL	Tam destek	DATABASECHANGELOG	Veritabanı bağımsız, diff
Alembic	Python	Python	Tam destek	alembic_version	SQLAlchemy entegrasyonu
Prisma Migrate	Node.js	Prisma Schema	Sınırlı	_prisma_migrations	Tip güvenli ORM
TypeORM	Node.js/TS	TypeScript	Tam destek	migrations tablosu	Entity senkronizasyonu
Django Migrations	Python	Python	Tam destek	django_migrations	ORM ile sıkı entegrasyon
Knex.js	Node.js	JavaScript	Tam destek	knex_migrations	Hafif, esnek
golang-migrate	Go	SQL	Tam destek	schema_migrations	CLI odaklı, hızlı

Flyway vs Liquibase: Derinlemesine Karşılaştırma

Bu iki araç JVM ekosisteminin en yaygın tercihidir. Flyway, sade SQL dosyaları ile çalışır ve öğrenme eğrisi düşüktür. Dosya adlandırması V1__create_users_table.sql biçiminde yapılır ve araç dosyaları sırayla uygular. Migrasyon yazma süreci doğrudan SQL bilgisiyle tamamlanabilir, ek bir DSL öğrenme gereksinimi yoktur. Topluluk sürümü açık kaynaklıdır ancak rollback gibi gelişmiş özellikler ücretli Teams/Enterprise sürümünde sunulur.

Liquibase ise daha kapsamlı bir yaklaşım sunar. Changelog dosyaları XML, YAML veya SQL formatında yazılabilir. Veritabanı bağımsız changeset tanımları yapabilir, mevcut bir veritabanından otomatik changelog üretebilir ve iki veritabanı arasında diff alabilir. Preconditions mekanizması ile koşullu migrasyon tanımlanabilir. Büyük ve karmaşık projelerde birden fazla veritabanı motoruyla çalışıyorsanız Liquibase daha fazla esneklik sunar. Küçük ve orta ölçekli projelerde Flyway'in sadeliği yeterli olur ve ekibin hızlı adapte olmasını sağlar.

ORM Tabanlı Araçlar

Alembic, Prisma Migrate ve TypeORM gibi araçlar, ORM modeli ile veritabanı şemasını senkronize tutar. Model değişikliğinden otomatik migrasyon dosyası üretirler. Bu yaklaşım uygulama kodu ile şema arasındaki tutarlılığı garanti eder ve geliştirici deneyimini iyileştirir. Ancak karmaşık veri dönüşümleri veya performans gerektiren DDL işlemleri için el ile müdahale gerekebilir. Otomatik üretilen migrasyonları mutlaka gözden geçirin; aracın ürettiği SQL her zaman optimal olmayabilir. Özellikle büyük tablolarda indeks ekleme veya kolon tipi değişikliği gibi işlemlerde aracın ürettiği komut yerine online DDL araçlarına yönelmek gerekebilir.

Sıfır Kesinti Migrasyon Stratejileri

Production ortamında şema değişikliği yaparken uygulamanın kesintiye uğramaması kritik bir gerekliliktir. Bakım penceresi açmak her zaman mümkün değildir, özellikle 7/24 hizmet veren sistemlerde. Sıfır kesinti migrasyonu birkaç temel strateji üzerine kuruludur.

Expand-Contract Pattern

Bu desen, şema değişikliklerini iki aşamaya böler. Expand (Genişletme) aşamasında mevcut yapıyı bozmadan yeni yapıyı eklersiniz: yeni kolon, yeni tablo veya yeni indeks tanımlarsınız. Uygulama hem eski hem yeni yapıyla çalışabilir durumda olmalıdır.

Contract (Daraltma) aşamasında ise tüm uygulama sunucuları yeni kodu çalıştırdıktan ve yeni yapıyı kullandıktan sonra eski yapı kaldırılır.

Somut bir örnek: users tablosundaki name kolonunu first_name ve last_name olarak ayırmak istiyorsunuz. Expand aşamasında yeni kolonları ekler, uygulamayı hem eski hem yeni kolonları okuyacak şekilde güncellersiniz. Mevcut verileri yeni kolonlara kopyalarsınız. Contract aşamasında uygulamayı sadece yeni kolonları kullanacak şekilde günceller ve name kolonunu kaldırırsınız. Her adım ayrı bir deployment olarak yapılır ve herhangi bir noktada güvenle geri alınabilir.

Blue-Green Database Deployments

Blue-green deployment, iki paralel ortam kullanarak sıfır kesinti sağlar. Veritabanı katmanında bu strateji, uygulama katmanından daha karmaşıktır çünkü veritabanı durumlu (stateful) bir bileşendir.

Yaygın yaklaşım veritabanını paylaşımlı tutmak ve sadece uygulama katmanını blue-green yapmaktır. Şema değişiklikleri geriye uyumlu olarak tasarlanır, böylece hem eski hem yeni uygulama versiyonu aynı veritabanıyla çalışabilir. Tam blue-green veritabanı için replikasyon tabanlı çözümler veya veritabanı proxy katmanları (ProxySQL, PgBouncer) kullanılır; ancak bu yaklaşım operasyonel karmaşıklığı ciddi ölçüde artırır ve genellikle çok büyük ölçekli sistemlerde tercih edilir.

Geriye Uyumluluk ve Rollback Stratejileri

Her migrasyon geri alınabilecek şekilde tasarlanmalıdır. Pratikte bu birkaç önemli kural anlamına gelir:

• Kolon silmeyin, önce kullanımı durdurun: Bir kolonu kaldırmadan önce uygulamanın o kolonu artık kullanmadığından emin olun. En az bir deployment döngüsü, tercihen bir hafta bekleyin.
• Kolon tipini doğrudan değiştirmeyin: VARCHAR(50) olan bir kolonu INTEGER yapmak yerine, yeni kolon ekleyin, veriyi dönüştürün, uygulamayı güncelleyin, eski kolonu kaldırın.
• NOT NULL kısıtlamalarını kademeli ekleyin: Önce varsayılan değerle kolon ekleyin, mevcut verileri doldurun, sonra NOT NULL kısıtlaması uygulayın.
• Her migrasyon dosyasının yanında bir down scripti bulunsun: Otomatik oluşturulmuyorsa elle yazın ve test edin.

Rollback stratejisi hata anında ne yapılacağını önceden belirler. Küçük değişiklikler için down migrasyonu yeterlidir. Büyük değişikliklerde snapshot veya point-in-time recovery tercih edilebilir. Veri kaybı riski taşıyan durumlarda migrasyon öncesi yedek almak zorunludur.

Büyük Tablo Migrasyonları

Milyonlarca veya milyarlarca satır içeren tablolarda ALTER TABLE komutları dakikalar hatta saatler sürebilir. Bu süre boyunca tablo kilitlenir ve yazma işlemleri bloklanır. Online DDL araçları bu sorunu çözer:

Araç	Veritabanı	Yöntem	Avantaj
pt-online-schema-change	MySQL	Trigger tabanlı kopya	Kanıtlanmış, uzun süredir kullanılan
gh-ost	MySQL	Binlog tabanlı kopya	Trigger gerektirmez, daha az yük
pg_repack	PostgreSQL	Trigger tabanlı	VACUUM gerektirmeden tablo sıkıştırma
Online DDL (InnoDB)	MySQL 8.0+	Yerleşik motor desteği	Ek araç kurulumu gerektirmez

gh-ost (GitHub Online Schema Tool), GitHub tarafından geliştirilmiştir ve MySQL tablolarında kilitsiz şema değişikliği sağlar. Binlog akışını okuyarak değişiklikleri yeni tabloya yansıtır, trigger kullanmadığı için kaynak tabloya ek yük bindirmez. Migrasyon sırasında durdurup devam ettirebilir, hız sınırı koyabilir ve production yüküne göre otomatik yavaşlayabilirsiniz. Throttle mekanizması replica lag veya CPU kullanımına göre otomatik olarak migrasyonu yavaşlatır.

PostgreSQL tarafında ise sürüm 11 sonrasında birçok ALTER TABLE komutu (kolon ekleme, varsayılan değer atama) zaten kilitsiz çalışır. Kolon tipi değişikliği veya büyük indeks oluşturma gibi işlemler için CREATE INDEX CONCURRENTLY komutu ve batch güncelleme stratejileri kullanılır. Büyük tabloları batchler halinde güncellemek, tek bir UPDATE komutu yerine 10.000 satırlık parçalar halinde işlemek transaction log şişmesini önler.

Veri Migrasyonu: ETL vs Streaming

Şema migrasyonu yanında verilerin bir sistemden diğerine taşınması da sık karşılaşılan bir gereksinimdir. İki temel yaklaşım vardır:

ETL (Extract-Transform-Load): Veriyi kaynaktan çeker, dönüştürür ve hedefe yükler. Batch işlemler için uygundur; Apache Spark, AWS Glue veya özel scriptler kullanılır. Büyük veri setlerinde tercih edilir ancak gerçek zamanlı değildir ve geçiş süresince veri tutarsızlığı yaşanabilir.

Streaming (CDC - Change Data Capture): Kaynak veritabanındaki değişiklikleri gerçek zamanlı yakalar ve hedefe yansıtır. Debezium, AWS DMS veya Oracle GoldenGate gibi araçlar kullanılır. Sıfır kesinti geçişleri için idealdir: kaynak ve hedef paralel çalışır, veriler tutarlı hale geldiğinde trafik yönlendirilir. Kritik sistemlerde ve yüksek yazma hacimli veritabanlarında genellikle CDC tercih edilir.

CI/CD Pipeline Entegrasyonu

Veritabanı migrasyonları uygulama dağıtım sürecinin ayrılmaz parçası olmalıdır. Manuel müdahale gerektiren her adım hata riski taşır. Pipeline entegrasyonu dört temel aşamadan oluşur:

1. Migrasyon dosyası oluşturma: Geliştirici yeni bir migrasyon dosyasını yazar ve uygulama koduyla birlikte commit eder. Code review sürecinde migrasyon dosyası da incelenir.

2. CI aşamasında doğrulama: Pipeline migrasyon dosyasının söz dizimini kontrol eder. Boş bir veritabanı üzerinde tüm migrasyonları sırasıyla çalıştırarak tutarlılık doğrulanır. Rollback scriptleri de test edilir. Bu adım Docker container içinde ephemeral bir veritabanı kullanılarak saniyeler içinde tamamlanır.

3. Staging ortamında uygulama: Migrasyon staging veritabanına otomatik uygulanır. Entegrasyon testleri çalıştırılır ve şema ile uygulama uyumluluğu doğrulanır.

4. Production dağıtımı: Onay sonrası migrasyon production ortamına uygulanır. Migrasyon her zaman uygulama deployment öncesinde çalıştırılmalıdır, böylece yeni kod çalışmaya başladığında şema hazır olur.

Flyway ve Liquibase Maven/Gradle eklentileri ile doğrudan build sürecine entegre olur. ORM tabanlı araçlar uygulama başlangıcında migrasyonları otomatik çalıştırabilir, ancak production ortamında bu yaklaşım risklidir. Birden fazla uygulama instance aynı anda migrasyon çalıştırmaya kalkabilir. Migrasyonu ayrı bir pipeline adımı olarak yönetmek daha güvenlidir.

Multi-Tenant Veritabanı Migrasyon Zorlukları

SaaS uygulamalarında multi-tenant mimari migrasyon sürecini önemli ölçüde karmaşıklaştırır. Üç yaygın model ve zorlukları:

Paylaşımlı veritabanı, paylaşımlı şema: Tüm kiracılar aynı tablolarda bulunur. Migrasyon bir kez uygulanır ancak veri hacmi büyük olduğu için süre uzar. Bir kiracının verisi bozulursa tüm kiracılar etkilenir. Büyük tablolarda online DDL zorunlu hale gelir.

Paylaşımlı veritabanı, ayrı şema: Her kiracı kendi şemasına sahiptir. 500 kiracınız varsa migrasyon 500 kez çalıştırılır. Paralel çalıştırma ve hata yönetimi kritik hale gelir. Bir kiracının migrasyonu başarısız olduğunda diğerlerinin etkilenmemesi gerekir.

Ayrı veritabanı: Her kiracı kendi veritabanına sahiptir. En izole yaklaşımdır ancak migrasyon yönetimi en karmaşık olandır. Versiyon tutarsızlığı riskini yönetmek, tüm kiracıların durumunu izlemek ve başarısız migrasyonları tekrar denemek için özel bir orkestrasyon katmanı gerekir.

Multi-tenant migrasyonlarda temel prensipler: migrasyonları idempotent yazın (tekrar çalıştırılabilir olsun), kiracı bazında versiyon takibi yapın, başarısız kiracılar için yeniden deneme mekanizması kurun ve migrasyon durumunu merkezi bir dashboard ile izlenebilir kılın.

Migrasyon Test Stratejileri

Migrasyon testleri production ortamında sürpriz yaşamamak için zorunludur. Etkili bir test stratejisi dört katmandan oluşur:

Birim testler: Her migrasyon dosyasının SQL söz dizimi doğrulanır. Up ve down migrasyonları boş veritabanı üzerinde sırayla çalıştırılır. Tüm migrasyonlar uygulandıktan sonra şemanın beklenen durumda olduğu kontrol edilir.

Entegrasyon testleri: Production verisinin anonimleştirilmiş bir kopyası üzerinde migrasyon çalıştırılır. Edge case veriler (NULL değerler, çok uzun stringler, özel karakterler, Unicode) kontrol edilir. Veri hacmi gerçek ortamı yansıtmalıdır.

Performans testleri: Büyük tablolarda migrasyon süresi ölçülür. Kilit süresi ve etkisi analiz edilir. Production yükü altında simülasyon yapılır. Kabul edilebilir süre aşılıyorsa online DDL araçlarına geçiş planlanır.

Rollback testleri: Her migrasyonun geri alınabilirliği doğrulanır. Up-down-up döngüsünün veri kaybına yol açmadığı teyit edilir. Rollback sonrası uygulamanın doğru çalıştığı kontrol edilir.

Migrasyon Yönetiminde Altın Kurallar

Yılların deneyiminden süzülen pratik kurallar:

• Tek sorumluluk: Her migrasyon dosyası tek bir değişikliğe odaklanmalı. Bir dosyada hem tablo oluşturup hem veri dönüştürmeyin.
• Değiştirme yasağı: Uygulanmış migrasyon dosyalarını asla değiştirmeyin. Hata varsa yeni bir migrasyon ile düzeltin.
• Süre ölçümü: Production veritabanı boyutunda migrasyon süresini mutlaka ölçün. Dakikalar kabul edilebilir, saatler planlanmalıdır.
• Sıra garantisi: Zaman damgası tabanlı isimlendirme kullanarak çakışma riskini azaltın.
• Seed ayrımı: Referans ve test verilerini migrasyon dosyalarından ayırın ve ayrı bir mekanizma ile yönetin.
• Loglama: Her migrasyon adımını loglayin; hata anında hangi adımda kalındığı anlaşılabilsin.

Sonuc

Veritabanı migrasyon yönetimi, olgun bir yazılım geliştirme sürecinin olmazsa olmaz parçasıdır. Doğru araç seçimi, sıfır kesinti stratejileri ve CI/CD entegrasyonu ile şema değişiklikleri uygulama dağıtımı kadar güvenli ve tekrarlanabilir hale gelir.

Smart Maple olarak Ankara merkezli yazılım projelerimizde veritabanı migrasyon süreçlerini en baştan doğru kuruyoruz. Flyway, Liquibase veya ORM tabanlı araçlarla CI/CD pipeline entegrasyonu, sıfır kesinti migrasyon stratejileri ve multi-tenant mimari desteği sunuyoruz. Veritabanı altyapınızı profesyonel seviyeye taşımak istiyorsanız bizimle iletisime gecebilirsiniz.