Veritabanı Migration'ı

Bir veritabanı migration'ı, bir veritabanı şemasında yapılan artımlı bir değişikliği tanımlayan, versiyon kontrolüne alınmış tek bir dosyadır — bir tablo oluşturmak, bir sütun eklemek, bir indeks eklemek gibi — ve her ortamda (bir geliştiricinin bilgisayarı, staging, üretim) sabit bir sırayla uygulanacak şekilde tasarlanır; böylece birinin elle `ALTER TABLE` komutları çalıştırıp her ortamın senkron kalmasını ummasına gerek kalmadan şema her yerde birebir aynı ve yeniden üretilebilir kalır. AI/SaaS geliştiricileri için neden önemli: migration'lar, bir şemanın büyüyen bir ürünle birlikte güvenli şekilde evrilmesini sağlayan mekanizmadır — yeni bir RAG özelliği için `embedding vector(1536)` sütunu eklemek, çok kiracılı (multi-tenant) izolasyonu zorunlu kılmak için bir `tenant_id` sütunu eklemek ya da yavaş bir sorguyu düzeltmek için bir indeks eklemek — bunların hepsi migration'dır ve bağlı oldukları uygulama koduyla birlikte versiyon kontrolüne kaydedilir; böylece geçmişteki herhangi bir commit'in `git checkout`'u, bir migration aracının birebir yeniden üretebileceği bir şemaya karşılık gelir. Nasıl çalışır: migration araçları (Laravel'in yerleşik migration sistemi, Prisma Migrate, Python için Alembic, Rails migration'ları) hangi migration'ların zaten çalıştırıldığını takip eder (genelde veritabanının kendisindeki özel bir `migrations` tablosunda) ve `migrate` komutu çalıştırıldığında yalnızca yeni olanları sırayla uygular. Migration'lar, mümkün olduğunda geri alınabilir şekilde yazılır (bir `up` adımı ve bir `down` adımı) ki kötü bir deploy temiz şekilde geri alınabilsin. Üretim sistemlerinde asıl zor kısım migration yazmak değil — canlı, yoğun trafikli bir veritabanına kesintisiz şekilde güvenle uygulamaktır: bir sütun eklemek genellikle güvenli ve hızlıdır, ancak mevcut büyük bir tabloya `NOT NULL` kısıtı eklemek veya bir indeks oluşturmak, dikkatli yapılmadığı sürece tabloyu kilitleyip yazma işlemlerini süre boyunca engelleyebilir (örneğin Postgres'in `CREATE INDEX CONCURRENTLY` komutu, tablo genelinde kilit tutmadan indeks oluşturur; bunun bedeli ise daha uzun sürmesi ve transactional olmamasıdır). Somut örnek: SaaS ürününe vektör arama ekleyen bir ekip, `AddEmbeddingToDocuments` adlı bir migration yazar; bu migration önce `ALTER TABLE documents ADD COLUMN embedding vector(1536);` komutunu, ardından `CREATE INDEX CONCURRENTLY ON documents USING hnsw (embedding vector_cosine_ops);` komutunu çalıştırır — concurrent indeks oluşturma, 5 milyon satırlık bir tabloda dakikalarca süren indeks oluşturma boyunca üretim veritabanının canlı okuma ve yazmalara hizmet vermeye devam etmesini sağlar; bloklayan, concurrent olmayan versiyon ise işlem bitene kadar tabloya yazmaları kilitlerdi. Bu migration, tam da bu üretim güvenliği endişesi yüzünden merge edilmeden önce peer review'dan geçer — ekibin trafik desenlerine aşina bir reviewer, `CONCURRENTLY` olmadan yapılan saf `CREATE INDEX` komutunun documents tablosunu mesai saatlerinde yazma işlemleri için çevrimdışı bırakacağını fark eder; bu tür bir hata, birkaç yüz satırlık yerel bir geliştirme ortamında görünmez, yalnızca üretim ölçeğinde belirginleşir.