Git'i veritabanı olarak kullanan paket yöneticileri eninde sonunda başarısız oluyor

 (nesbitt.io)
7 puan yazan GN⁺ 2025-12-27 | 2 yorum | WhatsApp'ta paylaş
  • Birçok paket yöneticisi, sürüm yönetimi ve iş birliği kolaylığı nedeniyle Git'i veritabanı gibi kullandı, ancak ölçek büyüdükçe performans ve bakım sorunlarıyla karşılaştı
  • Cargo, Homebrew, CocoaPods gibi araçlar; Git indeksinin büyümesi, yavaş güncelleme hızı ve CI ortamlarındaki verimsizlik nedeniyle sonunda HTTP tabanlı indekslere veya CDN'lere geçti
  • vcpkg hâlâ Git ağaç hash'lerine dayanarak çalışıyor ve sığ klon (shallow clone) ortamlarında derleme hataları ve karmaşık geçici çözümler ortaya çıkıyor
  • Go modül sistemi, Git bağımlılığını kaldırmak ve güvenlik ile hızı iyileştirmek için GOPROXY ve checksum veritabanını (sumdb) devreye aldı
  • Git, kod üzerinde iş birliği için mükemmel olsa da paket meta verisi sorguları veya büyük ölçekli kayıt defteri yönetimi için uygun olmadığını tekrar tekrar gösteriyor

Git'i veritabanı olarak kullanma denemelerinin tekrarlayan başarısızlığı

  • Git; sürüm geçmişi, dağıtık yapı, ücretsiz barındırma gibi avantajları nedeniyle çekici, ancak veritabanı olarak kullanıldığında ölçeklenebilirlik sınırlarına çarpıyor
  • Birçok paket yöneticisi Git'i indeks olarak benimsedi, ancak zamanla performans düşüşü ve altyapı yükü ağırlaştı

Cargo

  • crates.io indeksi bir Git deposu olarak başladı ve tüm istemciler tam kopya (clone) alıyordu
    • Depo büyüdükçe delta resolution aşamasında libgit2 performans darboğazı ortaya çıktı
    • CI ortamlarında her derlemede tüm indeksin indirilmesi ciddi israfa yol açtı
  • RFC 2789 ile sparse HTTP protokolü devreye alındı ve yalnızca gerekli meta verilerin HTTPS üzerinden alınması sağlandı
    • Nisan 2025 itibarıyla isteklerin %99'u sparse modu kullanıyor
    • Git indeksi hâlâ var, ancak kullanıcıların çoğu artık ona erişmiyor

Homebrew

  • GitHub, Homebrew'den sığ klon kullanımını durdurmasını istedi; güncellemeler “çok pahalı işlemler” olarak tanımlandı
    • homebrew-core'un .git klasörü 1GB'a yaklaştı ve güncelleme sırasında delta resolution nedeniyle gecikme yaşandı
  • Şubat 2023'te Homebrew 4.0.0, tap güncellemelerini JSON indirme yöntemiyle almaya geçti
    • Git fetch'in kaldırılması güncelleme hızını artırdı, otomatik güncelleme aralığı da 5 dakikadan 24 saate çıkarıldı
    Reklam

CocoaPods

  • iOS/macOS paket yöneticisi CocoaPods'un yüz binlerce podspec'ten oluşan Specs deposu aşırı büyüdü
    • Klonlama ve güncelleme dakikalar sürüyordu, CI süresinin büyük kısmı Git işlemlerinde harcanıyordu
  • GitHub, CPU rate limit uyguladı ve sunucu yükünün nedeni olarak shallow clone gösterildi
  • Ekip, otomatik fetch'i durdurma, tam klona geçme, depoyu shard'lara bölme gibi geçici önlemler aldı
  • 1.8 sürümünden itibaren CDN tabanlı HTTP dağıtımına geçildi; kullanıcı başına yaklaşık 1GB disk alanı tasarrufu sağlandı ve kurulum hızı ciddi biçimde arttı

Nixpkgs

  • Nix, istemci tarafında zaten tarball tabanlı kanallar kullandığı için Git klonlamasından kaçınıyor
    • Paket ifadeleri S3 ve CDN üzerinden HTTP ile sunuluyor
  • Ancak GitHub altyapısı, 83GB büyüklüğündeki depo ve 20.000 fork nedeniyle yük altında kaldı
    • Kasım 2025'te GitHub, replikalar arasında uzlaşma hataları ve bakım işlemi sorunları bildirdi
    • Yerel klon 2.5GB olsa da tüm fork ağı GitHub depolama alanı üzerinde baskı oluşturuyor

vcpkg

  • Microsoft'un C++ paket yöneticisi vcpkg, sürümlemeyi Git ağaç hash'leri ile yapıyor
    • builtin-baseline ile belirli bir commit anındaki portları yeniden üretmek için tüm geçmişe ihtiyaç duyuluyor
    Reklam
  • Sığ klon ortamlarında (GitHub Actions, DevContainers) derleme hataları oluşuyor
    • Çözüm olarak fetch-depth: 0 ayarı gerekiyor; bu da tüm geçmişin indirilmesini zorunlu kılıyor
  • Git ağaç hash yapısı nedeniyle commit takibi yapılamıyor; bu, yapısal bir sınır olduğu için düzeltilemiyor
  • Hâlâ yalnızca Git deposu tabanlı kayıt defterlerini destekliyor; HTTP veya CDN alternatifi yok

Go modül sistemi

  • Grab mühendislik ekibi, modül proxy'sinin devreye alınmasından sonra go get süresini 18 dakikadan 12 saniyeye indirdi
  • Eski yöntemde go.mod dosyasını okuyabilmek için her bağımlılığın tüm deposunun klonlanması gerekiyordu
  • Go ekibi, VCS araç bağımlılığı ve güvenlik açıklarından endişe duyuyordu
  • Go 1.13 ile birlikte GOPROXY varsayılan hâle geldi; modül kaynakları ve go.mod HTTP üzerinden sunuluyor
    • sumdb (checksum veritabanı) ile modül bütünlüğü ve kalıcılığı güvence altına alınıyor

Git'i veritabanı olarak kullanmanın genel sorunları

  • Git tabanlı wiki'ler (Gollum), büyük depolarda dizin gezintisi ve sayfa yüklemede yavaşlıyor
    • GitLab, Gollum kullanımını bırakmayı planlıyor
  • Git tabanlı CMS'ler (Decap), GitHub API istek sınırına (5.000) takılıyor
    • Yaklaşık 10.000 öğeden sonra performans düşüyor; önbelleği boş olan yeni kullanıcılar istek patlamasına yol açıyor
    Reklam
  • GitOps araçları (ArgoCD), depo klonlarken disk alanı aşımı sorunu yaşıyor
    • Tek bir commit tüm önbelleği geçersiz kılıyor; büyük monorepo'lar için ayrı ölçeklendirme gerekiyor

Git'in veritabanı olarak yapısal açıdan neden uygun olmadığı

  • Dizin sınırı: Dosya sayısı arttıkça yavaşlıyor
    • CocoaPods, 16.000 dizin nedeniyle devasa ağaç nesneleri üretiyordu; bunu hash tabanlı shard'lama ile çözdü
  • Büyük/küçük harf duyarlılığı sorunu: Git ayırt ediyor, ancak macOS ve Windows etmiyor
    • Azure DevOps, çakışmaları önlemek için sunucu tarafı engelleme özelliği ekledi
  • Yol uzunluğu sınırı: Windows'un 260 karakter sınırı nedeniyle git status hataları oluşuyor
  • Veritabanı özelliklerinin yokluğu:
    • CHECK/UNIQUE kısıtları, kilitleme, indeksleme ve migration özelliklerinin hiçbiri yok
    • Her paket yöneticisinin kendi doğrulama ve indeksleme sistemini kurması gerekiyor

Sonuç

  • Git, kaynak kodu üzerinde iş birliği için mükemmel olsa da paket meta verisi sorguları veya büyük ölçekli kayıt defteri yönetimi için uygun değil
  • Paket yöneticilerinin çoğu sonunda HTTP tabanlı indekslere veya veritabanlarına geçti
  • Git'in avantajları (sürüm geçmişi, PR iş akışı) çekici olsa da veritabanı yerine geçme denemesi başarısız oluyor
  • Yeni bir paket yöneticisi tasarlanırken Git indeksi cazip görünse bile Cargo, Homebrew, CocoaPods, vcpkg ve Go örneklerinde olduğu gibi aynı sınırlara ulaşılıyor

İlgili okumalar

2 yorum

 
GN⁺ 2025-12-27
Hacker News yorumları

  • Bu bir tür ortakların trajedisi gibi görünüyor. GitHub ücretsiz ve birçok harika özelliğe sahip olduğu için herkes onu kullanmak istiyor. Ama bu tür kararlar, dışsallıklar olduğunda hep ortaya çıkar
    Benim en önemli gördüğüm dışsallık kullanıcı zamanı. Çoğu yazılım şirketi yalnızca mühendislik zamanının maliyetini önemser, kullanıcı zamanını ise görmezden gelir. Özellik geliştirmeye odaklanırlar ama kullanıcı etkileşim süresini optimize etmezler. Örneğin, bir uygulamayı 1 saniye daha hızlı yapmak için 1 saat harcarsam, bir milyon kullanıcı yılda toplam 277 saat tasarruf eder. Ama kullanıcı zamanı bir dışsallık olduğu için bu tür optimizasyonlar neredeyse hiç yapılmaz
    Sonuçta kullanıcı gereksiz yere daha fazla veri indirir ve bekler, geliştirici de bu israfın sorumluluğunu üstlenmez

    • “Yazılım evi” ifadesinin tam olarak ne anlama geldiğinden emin değilim ama çalıştığım çoğu tüketici yazılımı ürünü, açılış hızı ya da gecikme gibi metrikleri temel olarak takip ediyordu. Bunlar onlarca yıldır bilinen şeyler. Mesela Amazon’un sayfa yüklenmesindeki birkaç milisaniyelik fark yüzünden milyonlarca dolar kaybettiğine dair hikâyeler sık sık anlatılırdı
    • Bu, “hız da bir **özellik(feature)**tir” sözüyle aynı bağlamda. Ancak kullanıcı zamanı yalnızca performansa değil, UI tasarımına da büyük ölçüde bağlıdır
    • Bunun “ortakların trajedisi” olduğunu düşünmüyorum. GitHub Microsoft’a ait, yani bunun maliyetini kaldırabileceklerine karar vermişlerdir. Gerçek bir ortak alan kimsenin sahip olmadığı ve herkesin faydalandığı bir yapı olmalı
    • Bu mesele üzerine derin düşününce Alan Kay’in şu sözü akla geliyor — “Yazılımı gerçekten önemsiyorsanız donanımı da kendiniz yapmalısınız.” Ağ üzerinden yükleme, özünde kötü bir kullanıcı deneyimidir. Kullanıcıya gerçekten saygı duyuyorsanız local-first(native-first) uygulamalar yapmalısınız. Ama kullanıcı deneyimine bu kadar saygı duyan şirket çok az
    • Andy Hertzfeld’in “Saving Lives” yazısında ilginç bir anekdot var — “Macintosh çok yavaş açılıyor. Onu daha hızlı yapmalıyız!”

  • Ben C için bir Cargo/UV geliştiriyorum. Güzel bir yazı, çok güçlü şekilde katılıyorum.
    Başlangıçta registry işletmek gerçekten zor. Yalnızca kod yazmak, araç kalitesini sağlamak ve topluluğu büyütmek değil; dünya çapındaki trafiği kaldıracak altyapıyı da düşünmek gerekiyor. Bu durumda git tabanlı çözümler cazip geliyor
    Ama asıl sorun sparse checkout. Paket manifestlerini git ile versiyonlamak istiyorum ama rastgele commit’leri takip etmek gerektiği için verimsiz oluyor. Sonunda iki ayrı commit push etmeniz gereken bir yapı çıkıyor, bu da pratikte uygulanamaz
    Conan yaklaşımının en pratik yol olduğunu düşünüyorum. Tam yeniden üretilebilirlik yerine manifestin içine koşullu mantık koyuyor. Sürüm aralıklarına göre manifest eşlemesi de mümkün. Mükemmel değil ama pratik ve faydalı bir uzlaşma.
    Elbette gerçek çözüm bir veritabanı kullanmak ama sunucu ve bakım masraflarını kimse sizin yerinize ödemeyeceği için pratikte zor

    • Perspektifi değiştirirsek, başarılı paket yöneticilerinin çoğu ilk başta Git tabanlı başladı ve ihtiyaç duyduklarında daha verimli bir yapıya geçti
    • Arch Linux AUR yaklaşımı da düşünmeye değer. Her paketin bağımsız bir git deposu olur ve yalnızca manifesti içerir. Böylece monorepo sorunundan ve referans kâbusundan kaçınılabilir
    • S3 gibi basit bir HTTP backend ile depo işletmek de cazip. Başta tek bir sunucuyla başlanır, popülerlik gelirse sponsor bulunup buluta taşınır.
      Para ve bağımsızlık sorun oluyorsa P2P yaklaşımı da mümkün. Tabii CI cache yoksa trafik patlayabilir
    • Henüz çok kullanıcı yoksa, dünya çapı altyapıyı baştan kurmaya çalışmak erken optimizasyon olur
    • Kullanıcılara tüm geçmiş verilerini göstermek zorunda değilsiniz. Bir post-commit hook ile yalnızca HEAD durumunu statik dosya olarak render edip GitHub Pages benzeri şekilde sunabilirsiniz.
      Debian, Fedora, openSUSE gibi Linux dağıtımlarının ayna yapısı da incelenmeye değer

  • Bu yazı iki ayrı sorunu birbirine karıştırıyor. Biri git’i paket indeks veritabanı olarak kullanmak, diğeri ise her paketin kodunu git ile almak. Bunlar ayrı meseleler.
    İndeks git ile, paketler zip/tar ile olabilir; ya da tam tersi de mümkündür. Go örneğinde ise zaten indeks diye bir yapı yok

    • Yazının yazarı biraz kafa karıştırmış gibi. “Tüm kullanıcılar veritabanını kopyalamasın” görüşüne katılıyorum ama bu, git grafiğinin veri kodlaması için kullanılamayacağı anlamına gelmez.
      GitHub’ın backend implementasyonu ya da 20 bin fork gibi konular özle alakasız. git working tree olmadan da verimli key-value sorguları yapılabilir.
      “git history rewrite, DB migration gibidir” iddiası da tuhaf. Bunun yerine tek bir Postgres çalıştırmak daha iyi olmaz mı?
    • Yazının asıl noktası kodun kendisi değil, go.mod dosyasını alma süreci. Bu yüzden çözüm olarak go.mod’u ayrı host etmeyi seçmişler
    • git ile de gereken tek dosyayı almak mümkün ama yine de yapısal olarak biraz eğreti duruyor

  • “Çalıştığı sürece kolay yolu seç, bozulursa düzeltiriz” yaklaşımı gerçekçi.
    Julia da aynı yöntemi kullanıyor ve paket sayısı Rust’ın yaklaşık yedide biri olduğu için henüz sorun yaşamıyor.
    Yalnızca üst düzey Registry.toml dosyasını indirip sadece gereken paketleri çekmek üzere iyileştirilebilir. Büyük bir mesele değil

    • Julia, git registry’yi yalnızca resmî ledger olarak kullanıyor; gerçek istemci ise Pkg Protocol kullanıyor
    • Bu yaklaşıma “FAFO(dene ve batır)” zihniyeti de denebilir. Pratik ama kişisel olarak pek sevmiyorum
    • Bu tavrın etik dışı olduğunu düşünüyorum. “Önce kolayca yapalım, sonra düzeltiriz” düşüncesi sonunda teknik borcu büyütüyor.
      “Move fast and break things” kültürünün sonucu bugün elimizdeki yavaş ve hatalı yazılımlar oldu
    • Sorunu sonra çözmek, maliyetin katlanarak artması demek. Sonunda varılan nokta “biraz bozuk haliyle kullanmaya devam edelim” oluyor. Yazıdaki vcpkg örneği de buna işaret ediyor
    • Birinin UUID’leri kasıtlı olarak manipüle etmiş gibi görünen örneği var; bunun mümkün olması biraz endişe verici

  • “Git, paket yöneticisi için başlangıç noktası olarak harika bir veritabanıdır” sonucuna katılıyorum

    • Ama istemci tüm depoyu indirmek yerine bir cache ya da DB katmanı kullanmalı. Özellikle CI/CD ortamında verimlilik önemli
    • Nixpkgs de Git sayesinde başarılı oldu. Ölçek sorunları daha sonra lüks dertlerdir
    • Ama Git’i övmeden önce biraz da veritabanı araştırmalarına bakmak faydalı olur
    • Git, tedarik zinciri açısından kâbusa da dönüşebilir. Leftpad olayı her hafta tekrarlanabilir
    • Git, paket yöneticisi veritabanı olarak berbat. İnsanlar sadece GitHub ücretsiz host ettiği için kullanıyor

  • Benim duruşum “sonuçta işe yaradı” yönünde. İlk operasyon döneminde yeterince fayda sağladı, ölçek sorunları ise sonra çözülebilirdi

    • Ama bazı projeler mimari sınırlar yüzünden git’ten çıkamıyor
    • git gibi dosya sistemi tabanlı store ile başlarsanız, sonradan protokol değiştirmek neredeyse imkânsız olur. En baştan API merkezli tasarım gerekiyor
    • Aslında git’i daha verimli kullanmak için fırsatlar var. Alternatif önermeden “git’i bırakın” demek yarım bir sonuç
    • “0’dan 1 trilyon kullanıcıya ölçeklenemedi diye çöp mü oldu?” şeklinde alaycı bir şaka da var

  • Burada bir hayatta kalan yanlılığı(survivorship bias) var. Cargo başarılı olduğu için git indeksi büyüyüp sorun haline geldi.
    Küçük projelerin çoğu git’i veri dağıtım protokolü olarak gayet iyi kullanıyor.
    Ölçeğin belirsiz olduğu başlangıç aşamasında git ve GitHub’dan yararlanıp asıl probleme odaklanmak mantıklı

    • Çok erken optimizasyondan kaçınmak gerekir. Cargo ve Homebrew de kolay yolu seçerek büyüdü; ölçek sorunları ise sonradan gelen “iyi problemlerdi”

  • HN ana sayfasında “şu an yaptığın şey yanlış” diyen bir yazı görünce insan her zaman biraz mütevazı oluyor.
    Ben de bunu birkaç kez yaşadım. Bu sefer konu PG Notify ile ilgiliydi.
    Ama şu anda projeyi tek başıma geliştiriyorum ve başarılı olup olmayacağını bile bilmiyorum; bu yüzden git ile eklenti dağıtmak en gerçekçi seçenek.
    Yine de ileride ölçek sorunu çıkarsa bu yazıya geri döneceğim

    • Yine de şimdiden bazı tuzaklardan kaçınmak mümkün. GitHub bağımlılığı gibi vendor lock-in daha büyük sorun olabilir

  • Ben şahsen kodumu Forgejo üzerinde host ediyorum. Dışarıya açmadan mTLS ile koruyorum.
    Ama Go modülleri sertifika talep ettiği için benim Forgejo instance’ımı tanımıyor.
    SSH kullansam bile HTTPS erişimi gerektiği söyleniyor, bu yüzden sonunda yerel kopyayı replace directive ile kullanıyorum. Oldukça uğraştırıcı

    • Modül yolunun sonuna .git ekleyip $GOPRIVATE ayarlarsanız HTTPS isteği olmadan git komutu kimlik doğrulaması kullanabilirsiniz. Resmî belgeye bakın
    • Instance’ın TLS sertifikasını(CA) güven deposuna eklerseniz HTTPS ile indirme de yapılabilir
    • “HTTP erişimi gerekiyor” ifadesi aslında doğru değil. Yerel proxy ile çözülebilir
    • Tailscale DNS ve sertifikaları ile dışarıya açmadan Let’s Encrypt sertifikası almak mümkün

  • Paket yöneticilerinin yanı sıra birçok küçük proje veriyi git depolarına crowdsourcing ediyor.
    Çoğu küçük ölçekte kaldığı için teknik sınırlara çarpmıyor.
    Ancak bu yapı, geliştirici olmayanların katılım eşiğini yükseltiyor. Paket yöneticileri için istisna olabilir ama genel projelerde sorun yaratıyor
    Ben de bu soruna yardımcı olmak için Datatig adlı açık kaynak bir kütüphane geliştirdim.
    İlgili sunum materyalleri burada. Gelecekte bu yazıyı referans alıp ölçekleme ile ilgili içerik de eklemeyi planlıyorum
 
lamanus 2025-12-28

Katkıda bulunanların katkılarını almak için ayrı bir sistem kurmak yerine, git daha pratik olduğu için onu kullanıyorlar. Buna bir sınırlama deniyor ama ben buna pek katılmıyorum; ayrıca gerçekçi sorunlara dair herhangi bir alternatif de hiç görünmüyor.