- 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ı
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
- 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
- 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
1 yorum
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.