127 tablo. Üç ay var gücüyle kodlama. Sadece 19 takip edilen göç.
Bu acımasız rakam bana asi bir asteroid gibi çarptı — canım PostgreSQL veritabanım, yayılmış bir imparatorluk gibi kodladığım o dev, takip edilmeyen şema değişikliklerinin gölge dünyasına dönmüştü. 100’den fazla sinsi ALTER, CREATE ve INDEX işlemi, acele SSH komutlarıyla sokuşturulmuş, her seferinde kendime “sonra göç dosyasını eklerim” diye söz verirken. Spoiler: Eklememiştim. Saatlerimi, aklımı ve bir dev pipeline çöküşünü feda ettim.
Ama işte bilimkurguvari dönemeç — bu sadece bir geliştirici korku hikayesi değil. Yapay zeka çağında kod ışık hızında uçarken veritabanı göçlerinin neden sessiz kahramanlar olduğunu gösteriyor. Şemanızı bir yıldız gemisinin warp çekirdeği gibi düşünün: Bakım kayıtlarını ihmal edin, plazma boşluğa akar. Bunu en zor yoldan öğrendim, paralel geliştirme seanslarında kafeinli bir mühendis gibi koştururken.
‘Hızlı SQL’ Frankenstein Veritabanına Dönüşünce
İlk hafta? Tertemiz. Numaralı SQL dosyaları, checksum’lar, kendini denetleyen bir göç tablosu. Sonra hız kaçış hızını aştı. Özellikler şema dokunuşu istiyordu — hemen. Docker’lı Postgres’e SSH’la girip ALTER TABLE pompalıyor, indeks ekliyor, hoop dağıtıyordum.
“SQL her zaman düzgün yazılmıştı. Değişiklik kendisi doğruydu. Atladığım şey, onu göç sistemine kaydetmekti. Her seferinde gerekçe aynı: özellik acil, şema değişikliği basit, işler yavaşlayınca göç dosyasını eklerim.”
İşler yavaşlamadı. Canlı veritabanı 127 tabloya şişti; göçler 60’ta kaldı. Paralel seanslar? Aynı tabloya sütunlar gelişigüzel ekleniyor — sorun yok, ta ki taze git pull şemayı eski sanana dek. Kod çarpışıyor. Hatalar patlıyor.
Ve ölümcül vuruş? İş akışı ortasında şema dokunuşu. E-posta işleyen sınıflandırma pipeline’ı, ‘devam ediyor’ diye işaretliyor ama yeni yapıya INSERT patlıyor. Sıkışmış kayıtlar. Saatlerce elle kazma. İnceleme adımı yoktu, “bunun üstünde canlı bir şey var mı?” diye soran.
100+ Değişiklik Postgres Şema Kaosunu Kurtarabilir misiniz?
Kısa cevap: Evet. Ama kirli, pragmatik bir savaş — sihir değil.
Önce enkazı denetleyin. 100 hayalet geriye takip etmek aptallık; aptal altını. Canavarı snapshot’layın: pg_dump –schema-only 9.756 satır saf yapı döküyor — tablolar, indeksler, kısıtlar, fonksiyonlar. Yeni taban çizginiz.
ORM bağımlı araçları eledim, Alembic gibi (ben raw SQL’cuyum, sadece asyncpg). Flyway? JVM şişkinliği. Sahneye dbmate çıkıyor: Tek binary, düz SQL up/down bölümleri, sıfır çerçeve karmaşası. Tam benim havam.
Dump’ı dönüştürün: dbmate işaretlerine sarın (–migrate:up, –migrate:down). Takip tablosunda uygulanmış diye işaretleyin. Eski geçmişi schema_migrations_legacy’ye taşıyın — fosilleri saklayın. dbmate status? Bir uygulanmış, sıfır bekleyen. Yeniden doğmuş.
Şimdi demir gibi kurallar: Önce göç dosyası. Yaz, incele, uygula. Geri alma bölümü zorunlu — basit bir DROP bile. Kuvvet alanı bu.
Bu angarya değil; özgürlük. Veritabanlarını kendi kendini iyileştiren organizmalar gibi hayal edin — yapay zeka oraya gidiyor, niyetten göç üretiyor. Benim iddiam? dbmate gibi araçlar şemayı izleyen, çakışmaları öngören, proaktif göç eden yapay zeka ajanlarının habercisi. GitHub Copilot gibi, ama Postgres kalbiniz için.
Git’in doğuşundan yankılar da var — versiyon kontrol öncesi kod kabile hafızası oyunu. Bir kötü merge, puff. Göçler veritabanı hızında aynı disiplini getiriyor.
Neden Geliştirme Işık Hızında Şema Göçleri Daha mı Önemli?
Düzeltme öncesi? Sürtünme şehri. Yeni seanslar antik git şemalarını çekiyor — kod var olmayan sütunlara çarpıyor ya da hayalet peşinde. Veri tuhaflığı? Tarih yok, iz süremezsiniz.
dbmate sonrası? Her değişiklik log’lu olay. Sıfırdan yeniden üretilebilir. Yıldız gemisi sallanırsa geri al. O sürekli sürükleme? Kayboldu. Güven fırınlanmış, geliştirme hızı uçuyor.
Kurumsal abartı buna “altyapı kod olarak” diyor. Yok ya — hayatta kalma kod
