Sqldef: MySQL, PostgreSQL ve SQLite için idempotent şema yönetim aracı

 (sqldef.github.io)
7 puan yazan GN⁺ 2026-02-10 | 1 yorum | WhatsApp'ta paylaş
  • SQL şemaları arasındaki farkı (diff) karşılaştırarak veritabanı migrasyonlarını yöneten CLI tabanlı araç
  • Yaygın SQL DDL sözdizimini kullanarak RDBMS şemaları yönetilebilir
  • MySQL, MariaDB, TiDB, PostgreSQL, SQL Server, SQLite3 gibi başlıca veritabanlarını destekler
  • Web sitesinde, WebAssembly build kullanan çevrim içi demo ile şema karşılaştırma ve DDL üretim işlevleri denenebilir
  • Veritabanı değişiklikleri idempotent olarak yönetilebilir; bu da kararlı şema senkronizasyonu için kullanışlıdır

sqldef genel bakış

  • sqldef, iki SQL şemasını karşılaştırıp (diff) farkları analiz eden ve buna dayanarak DDL komutları üreten bir CLI aracıdır
    • Kullanıcılar mevcut şema ile hedef şemayı karşılaştırarak gerekli değişiklikleri otomatik olarak çıkarabilir
    • Migrasyonlar, yaygın SQL DDL ifadeleri doğrudan kullanılarak gerçekleştirilebilir
  • Desteklenen veritabanları olarak MySQL, MariaDB, TiDB, PostgreSQL, SQL Server, SQLite3 belirtilir

Çevrim içi demo özellikleri

  • Web sitesinde, şema değişikliklerini görsel olarak incelemeyi sağlayan bir Online Demo sunulur
    • “Enable DROP” seçeneğiyle silme komutlarının dahil edilip edilmeyeceği kontrol edilebilir
    • “Up (current → desired)” bölümünde yeni sütun ekleme, indeks oluşturma, kısıt ekleme gibi örnek DDL'ler gösterilir
    • “Down (desired → current)” bölümünde kısıt kaldırma gibi ters yöndeki değişiklik örnekleri sunulur

Çalışma şekli

  • Çevrim içi demo, tarayıcı içinde SQL şema karşılaştırması (diff) yapmak için sqldef'in WebAssembly build sürümünü kullanır
    • İki şema arasındaki farkı hesaplar ve bunun sonucunda gerekli DDL komutlarını otomatik olarak üretir
    • GitHub depo bağlantısı üzerinden WebAssembly build kaynağı incelenebilir

İlgili okumalar

1 yorum

 
GN⁺ 2026-02-10
Hacker News yorumları

  • Postgres için daha kapsamlı bir kapsama istiyorsanız, benim yaptığım pgschema'ya bakmaya değer
    Geçen yaz epey tamamlandığını düşünmüştüm ama 6 ay boyunca kullanıcıların bildirdiği 100'den fazla sorunu çözerken ne kadar saf olduğumu fark ettim

    • Gerçekten harika bir araç. Ekibimizle birlikte bir PoC yapmayı planlıyoruz
      Birden fazla veritabanı kümesinde tutarsızlıkları denetleme desteği olup olmadığını merak ediyorum
    • Bana Migra'yı hatırlattı
    • Şema migration'ları için iyi görünüyor ama gerçekten veriyi taşımak gerektiğinde update/insert işlemlerinin nasıl ele alındığını merak ediyorum
    • Xata'nın pg_roll aracı da düşünülebilecek bir alternatif

  • SQLite ile denedim ama mevcut tabloya foreign key constraint eklemek gibi zor migration'larda geçersiz SQL üretiyor
    Örneğin ALTER TABLE books ADD CONSTRAINT fk_books_author FOREIGN KEY (author_id) REFERENCES authors (id) gibi bir ifade SQLite'ta geçerli değil
    İlgili dokümantasyon için SQLite ALTER TABLE

    • Yani foreign key eklemek için sonunda kolonu silip yeniden eklemek mi gerekiyor?

  • Ben Atlas'ı kullanıyorum
    Migration tabanlı ve şema tabanlı yaklaşımların ikisinin de artıları ve eksileri var, bu yüzden tek bir projede iki yöntemi birlikte kullanıyorum
    Şema tabanlı yaklaşım geliştirme hızını artırıyor, migration tabanlı yaklaşım ise daha güven veren deploy imkânı sunuyor

    • Atlas ekibinden Ariel burada. Lokalde deklaratif, gerçek ortamlarda ise versiyonlanmış yaklaşımı birlikte kullanmak yaygın bir kurulum
      Atlas PR içinde migration'ları otomatik ürettiği için çoğu geliştirici versiyonlu workflow ile doğrudan uğraşmıyor
      İlgili dokümanlar: Declarative vs Versioned Workflows, Atlas Action
    • Ben de sqldef ve diğer alternatiflere bakarken Atlas'ı buldum
      Açıkça tanımlanmış migration flow desteği hoşuma gitti. Gerçek deploy öncesinde tam olarak hangi değişikliklerin uygulanacağını bilmek istiyorum

  • Arka plan migration'larını destekleyen iyi bir araç olup olmadığını merak ediyorum
    Örneğin büyük bir tabloya geçici nullable bir kolon ekleyip, yeni kodun o kolona veri yazmaya başlamasından sonra arka planda mevcut veriyi batch'lerle doldurup en sonunda kolonu non-nullable yapmak gibi bir iş akışı
    Böyle prosedürel değişiklikleri deklaratif biçimde ifade edip kodla birlikte inceleyip test edebileceğimiz bir araç olsa iyi olurdu
    Şu anda bunu çoğunlukla geçici script'ler ve manuel deploy talimatlarıyla yapıyoruz

    • Ben şema migration'larını genelde elle yazıyorum ama çoğunlukla grate'i kullanıyorum
      Geliştirme ortamında kurulumu kolay ve FastEndpoints-SqlJobQueues gibi örnekleri var

  • Bu araç gerçekten harika
    Sayesinde aynı şeyi yapmaya çalıştığım hobi projemi bırakabileceğim
    Onun yerine zaten 100 kez çözülmüş başka bir problemi ele alan yeni bir projeye başlayacağım — örneğin systemd loglarını izleyip hata olunca e-posta gönderen basit bir araç gibi

  • Bir başka migration manager değil de küçük ve kullanışlı bir araç olması hoşuma gitti
    SQL'in zayıf yönlerini güzelce tamamlıyor gibi. Keşke Spanner DDL gibi deklaratif olsaydı diye düşündürüyor
    Postgres'te şema script'lerini idempotent tutmaya çalışıyorum. CREATE TABLE IF NOT EXISTS ile başlıyor, yeni kolon eklerken ALTER ifadelerini ayrı tutuyorum
    Ama zamanla script'ler karmaşıklaşıyor ve işler oturunca ALTER ifadelerini temizliyorum
    Eğer eski bir yedeği geri yüklemek gerekirse, böyle bir araç uyumluluğu hızlıca yakalamaya yardımcı olabilir gibi görünüyor

  • Entity Framework veya sqitch/liquibase ile karşılaştırınca nasıl olduğunu merak ediyorum
    Deklaratif yaklaşımı anlıyorum ama büyük prodüksiyon veritabanlarında migration'lar sadece deklaratif olmuyor
    İdeal bir şema yöneticisinin sorgu maliyeti ve kesinti süresini en aza indirme stratejilerini anlaması gerekir
    Kolon eklemek veya indeks değiştirmek tüm tablo taramasına yol açabilir

    • Daha büyük sorun, verinin kendisinin migration'ın bir parçası olabilmesi
      Örneğin Fullname alanını FirstName ve LastName olarak ayırırsanız, basit bir diff bunun ancak yarısını ifade eder
      EF Core'da geri alınabilir dönüşümler Up/Down metotlarıyla ele alınıyor
      Böyle bir kavram olmadan veri dönüşümlerinin nasıl yönetildiğini merak ediyorum

  • Biz şirket içinde XML tabanlı kendi dönüşüm aracımızı yaptık
    XML, SQL'e göre parse etmesi daha kolay olduğu için XML'de tanımlanan şemayla veritabanını karşılaştırıp sadece gerekli değişiklikleri uyguluyoruz
    Sybase SQLAnywhere kullanıyorduk ve materialized view işin içindeyken kolon ekleme/silmede view'ları ve indeksleri yeniden oluşturma karmaşıklığı vardı
    Bu yüzden güvenlik önlemleri ekledik; kolon silmeye yalnızca açıkça belirtildiğinde izin veriyoruz, tip değişikliklerini de sadece güvenli durumlarda yapıyoruz
    Yüzlerce on-premise kurulum ortamında migration'ları çok basit hale getiriyor
    Sadece XML'i değiştiriyorsunuz, araç geri kalanını hallediyor ve gerektiğinde yeni özellik ekleyebiliyorsunuz

  • SQLite'ta kolon silme konusu iyi işlemiyor
    Son sürümlerde DROP COLUMN eklendi ama çoğu cihazda hâlâ desteklenmiyor
    Örnekte x integer not null ekleyip DROP denendiğinde sadece “-- Skipped” mesajı çıkıyor
    Standart yöntem geçici tablo oluşturup veriyi kopyaladıktan sonra değiştirmek ama bu araç bunu otomatikleştirmiyor
    Constraint'ler devreye girdiğinde hata yapması kolay bir alan olduğu için bu biraz hayal kırıklığı yaratıyor
    Sonuçta sadece kolay işleri yapacaksa bunu elle yapmak daha mantıklı gibi geliyor

  • Bu araç yalnızca boş veritabanlarında faydalı görünüyor
    Veri migration'larını ele alamıyor; örneğin JSONB kolonunu yapısal bir forma dönüştürmek gibi durumlarda veya kolon silme sonrası geri migration sırasında ADD COLUMN … NOT NULL üretmesi nedeniyle gerçek veri içeren tablolarda kullanılamaz