Database Migration Nedir? 30 Dakikada Güvenli Geçiş

Meta Description

Database migration ile şema değişikliklerini güvenle yönetin. PostgreSQL + Prisma örneği, rollback ve CI ipuçlarıyla hemen uygulayın.

Giriş (Introduction)

Üretimde bir sütun eklemek “basit” görünür… ta ki gece yarısı deploy’unda locking, uzun süren ALTER TABLE, kırılan sorgular ve geri dönüş planı olmayan bir sürümle karşılaşana kadar. Kod versiyonlanıyor ama veritabanı şeması “elle” değişiyorsa, ekibin büyüdüğü an sorun kaçınılmaz olur.

Database migration, veritabanı şema değişikliklerini (tablo, kolon, index, constraint) kod gibi versiyonlayıp, tekrarlanabilir ve izlenebilir şekilde uygulamanın standardıdır. Bu yazıda database migration mantığını, en güvenli akışı ve gerçek hayatta işin nasıl yönetildiğini adım adım öğreneceksiniz.

Okuduğunuzda; staging/prod farklarını azaltacak, deploy’ları daha az riskli yapacak ve “geri alma (rollback) neydi?” paniklerini bitirecek bir temel kazanacaksınız.

---

Database Migration Nedir? (ve Neden Önemli?)

Database migration, veritabanı şemasındaki değişiklikleri sıralı dosyalar/komutlar halinde tanımlar ve ortamlar arasında aynı sırayla uygular.

Bunu neden yapmalıyım?

• Tekrarlanabilirlik: Local → staging → prod aynı değişiklikleri aynı sırayla alır.
• Versiyonlama: Kim, ne zaman, neyi değiştirdi sorusunun cevabı nettir.
• Deploy güvenliği: Uygulama kodu ile şema değişikliği birlikte yönetilir.
• Ekip çalışması: “Bende çalışıyor” şema farkları azalır.

LSI (ilişkili) kavramlar

• schema versioning (şema versiyonlama)
• rollback (geri alma)
• zero-downtime migration (kesintisiz migration)
• migration tool (Prisma, Flyway, Liquibase, Alembic)

---

Migration Türleri: Schema vs Data Migration

Migration deyince iki ana sınıf var:

Tür	Ne değişir?	Örnek	Risk
Schema migration	Tablo/kolon/index/constraint	ADD COLUMN, CREATE INDEX	Locking, uzun süren DDL
Data migration	Verinin kendisi	Eski kolonu yeni kolona taşımak	Performans, tutarlılık

Gerçek hayattan örnek

E-ticaret uygulamasında users.full_name alanını first_name ve last_name olarak bölmek:

• Schema: iki kolon ekle
• Data: full_name’den parçala, yeni kolonlara yaz
• Uygulama: önce iki alanı da okuyup/yazabilen sürüm
• Temizlik: eski kolonu kaldır

---

İyi Bir Migration Akışı (Güvenli ve Sürdürülebilir)

Kesintisiz deploy hedefliyorsanız, migration’ı “tek hamlede her şeyi değiştir” mantığıyla değil, aşamalı yürütün.

1) Expand → Migrate → Contract yaklaşımı

1. Expand (genişlet): Yeni kolon/tabloyu ekle (mevcut kod bozulmasın)
2. Migrate (taşı): Veriyi arka planda/cron ile yeni yapıya taşı
3. Contract (daralt): Eski alanları kaldır

Bu yaklaşım özellikle yüksek trafikli sistemlerde zero-downtime migration için kritiktir.

2) Geri alma (rollback) planı yap

Her migration için şu soruyu sorun:

• “Bu deploy geri alınırsa DB tarafında ne olacak?”
• “Down migration mümkün mü, yoksa forward-fix mi yapacağız?”

Not: Bazı ekipler down migration’ı prod’da bilerek kullanmaz. Bunun yerine ileriye dönük düzeltme (forward migration) tercih eder. Önemli olan stratejinin net olmasıdır.

---

PostgreSQL’de Migration Yaparken Dikkat Edilecekler

Locking ve uzun süren DDL

Bazı DDL işlemleri tabloyu kilitleyebilir. Örn: büyük tabloda ALTER TABLE ... TYPE.

Ne yapmalı?

• Büyük tabloda riskli değişiklikleri küçük adımlara böl
• Trafiğin düşük olduğu zamanlarda uygula
• Mümkünse online alternatifleri değerlendir

Concurrent index oluşturma

PostgreSQL’de index eklemek bazı durumlarda ciddi kilit yaratabilir.

Öneri: Büyük tablolar için:

• CREATE INDEX CONCURRENTLY ...

Dikkat: CONCURRENTLY bazı migration araçlarında transaction içinde çalışmaz. Tool’unuzun davranışını öğrenin.

---

30 Dakikada Uygulama: Prisma ile Database Migration (PostgreSQL)

Bu bölümde pratik bir akış yapalım. Örnek: orders tablosuna status alanı ekleyelim.

Ön koşullar

• Node.js
• PostgreSQL
• Prisma

1) Prisma kurulumu ve init

npm init -y
npm i prisma @prisma/client
npx prisma init

.env içine bağlantı:

DATABASE_URL="postgresql://user:pass@localhost:5432/appdb"

2) Şemayı güncelle

prisma/schema.prisma:

model Order {
  id        String   @id @default(cuid())
  createdAt DateTime @default(now())
  status    String   @default("pending")
}

3) Migration üret ve uygula

npx prisma migrate dev --name add_order_status

Bu komut:

• prisma/migrations/... altında SQL oluşturur
• DB’ye uygular
• Prisma Client’ı günceller

4) Prod ortamında nasıl uygulanır?

Prod’da genelde migrate deploy kullanılır:

npx prisma migrate deploy

5) Basit doğrulama

npx prisma studio

Ve Order kayıtlarında status alanını kontrol edin.

---

CI/CD’de Migration’ı Nereye Koymalıyım?

Migration’ı deploy pipeline’ına koymak iyi bir pratiktir; ama doğru sırayla.

Önerilen sıra

1. Uygulama backward-compatible kodu deploy et (eski şema ile de çalışabilsin)
2. Migration’ı çalıştır (migrate deploy / flyway migrate)
3. Yeni şemayı kullanan değişiklikleri kademeli aç (gerekirse feature flag)

Mini kontrol listesi

• Migration staging’de gerçek veri benzeri dataset ile denendi mi?
• Süre ölçüldü mü? (kaç saniye/dakika)
• Lock riski var mı?
• Rollback/forward-fix planı yazıldı mı?
• Observability: migration sırasında hata/timeout izleniyor mu?

---

Sık Yapılan Hatalar (ve Nasıl Kaçınılır?)

1) Tek migration’da “her şeyi” yapmak

Çözüm: Expand → Migrate → Contract.

2) Büyük tabloda riskli DDL

Çözüm: Trafik düşükken uygula, adım adım ilerle, alternatif strateji planla.

3) Uygulama kodu ile DB şemasını senkron götürmemek

Çözüm: PR sürecinde migration dosyasını zorunlu hale getir.

4) Migration’ı test etmeden prod’a almak

Çözüm: Staging + prod’a yakın veri hacminde performans testi.

---

Sık Sorulan Sorular (FAQ)

1) Database migration nedir, neden gereklidir?

Database migration, şema değişikliklerini versiyonlayıp ortamlara aynı şekilde uygulamayı sağlar. Deploy güvenliğini ve ekip uyumunu artırır.

2) Migration ile seed (örnek veri) aynı şey mi?

Hayır. Migration şemayı (ve gerekirse dönüşüm verisini) yönetir; seed genelde başlangıç/test verisi yüklemek içindir.

3) Prod’da down migration (rollback) kullanmalı mıyım?

Her zaman değil. Bazı durumlarda geri almak riskli olabilir; bunun yerine forward-fix migration tercih edilir. Önemli olan planın önceden belirlenmesi.

4) Migration sırasında uygulama kesintiye girer mi?

Doğru stratejiyle (aşamalı değişiklik, backward-compatible kod, uygun DDL) çoğu değişiklik kesintisiz yapılabilir; ancak bazı DDL’ler lock yaratabilir.

5) Hangi migration aracını seçmeliyim?

ORM kullanıyorsanız (Prisma, Django, SQLAlchemy) kendi migration sistemi yeterli olabilir. Kurumsal/DB-odaklı ekiplerde Flyway/Liquibase daha güçlü yönetim sunar.

---

Sonuç

Database migration, veritabanını “elle yönetilen bir parça” olmaktan çıkarıp, yazılım teslim sürecinin güvenilir bir parçası haline getirir. Bu yazıda migration’ın ne olduğunu, schema/data ayrımını, güvenli stratejiyi (Expand → Migrate → Contract) ve Prisma ile hızlı bir uygulamayı gördünüz.

Bir sonraki deploy’unuzda şunu deneyin: Küçük bir şema değişikliğini migration ile çıkarın, staging’de süre/lock etkisini ölçün ve CI/CD’ye ekleyin.

İsterseniz yorumlara; kullandığınız veritabanını (PostgreSQL/MySQL/MongoDB) ve migration aracınızı yazın, size sıfır kesinti hedefiyle en uygun akışı önereyim.