Manajer paket yang menggunakan Git sebagai database pada akhirnya gagal

 (nesbitt.io)
7 poin oleh GN⁺ 2025-12-27 | 2 komentar | Bagikan ke WhatsApp
  • Berbagai manajer paket menggunakan Git seperti database karena kemudahan versioning dan kolaborasi, tetapi ketika skalanya membesar mereka akhirnya menghadapi masalah performa dan pemeliharaan
  • Cargo, Homebrew, CocoaPods, dan lainnya pada akhirnya beralih ke indeks berbasis HTTP atau CDN karena ukuran indeks Git yang terus membesar, kecepatan pembaruan yang lambat, dan inefisiensi di lingkungan CI
  • vcpkg masih beroperasi berdasarkan hash tree Git, dan di lingkungan shallow clone muncul kegagalan build serta solusi workaround yang rumit
  • Sistem modul Go menghilangkan ketergantungan pada Git dengan memperkenalkan GOPROXY dan database checksum (sumdb), sehingga keamanan dan kecepatan meningkat
  • Git sangat unggul untuk kolaborasi kode, tetapi berulang kali terbukti tidak cocok untuk kueri metadata paket atau pengelolaan registry berskala besar

Kegagalan berulang dari upaya menggunakan Git sebagai database

  • Git menarik karena keunggulannya seperti riwayat versi, struktur terdistribusi, dan hosting gratis, tetapi ketika digunakan sebagai database ia terbentur batas skalabilitas
  • Banyak manajer paket mengadopsi Git sebagai indeks, namun seiring waktu penurunan performa dan beban infrastruktur makin parah

Cargo

  • Indeks crates.io dimulai sebagai repositori Git, dan semua klien melakukan clone penuh
    • Saat repositori membesar, muncul bottleneck performa libgit2 pada tahap delta resolution
    • Di lingkungan CI, seluruh indeks diunduh pada setiap build sehingga pemborosan menjadi serius
  • Melalui RFC 2789, diperkenalkan protokol sparse HTTP sehingga hanya metadata yang diperlukan yang diambil lewat HTTPS
    • Per April 2025, 99% permintaan menggunakan mode sparse
    • Indeks Git masih ada, tetapi sebagian besar pengguna tidak lagi mengaksesnya

Homebrew

  • GitHub meminta Homebrew untuk berhenti menggunakan shallow clone, dan pembaruan disebut sebagai “operasi yang sangat mahal”
    • Folder .git pada homebrew-core mendekati 1GB, dan saat pembaruan terjadi keterlambatan akibat delta resolution
  • Pada Februari 2023, Homebrew 4.0.0 mengubah pembaruan tap ke metode unduhan JSON
    • Dengan menghapus Git fetch, kecepatan pembaruan meningkat, dan interval auto-update juga berubah dari 5 menit menjadi 24 jam

CocoaPods

  • Manajer paket iOS/macOS CocoaPods memiliki repositori Specs berisi ratusan ribu podspec yang menjadi terlalu besar
    • Clone dan pembaruan memakan waktu beberapa menit, dan sebagian besar waktu CI habis untuk operasi Git
  • GitHub menerapkan CPU rate limit, dan shallow clone ditunjuk sebagai penyebab beban server
  • Tim menerapkan langkah sementara seperti menghentikan fetch otomatis, beralih ke full clone, dan sharding repositori
  • Sejak versi 1.8, sistem ini beralih ke distribusi HTTP berbasis CDN, menghemat sekitar 1GB ruang disk pengguna dan sangat meningkatkan kecepatan instalasi

Nixpkgs

  • Nix di sisi klien sudah menggunakan channel berbasis tarball untuk menghindari clone Git
    • Ekspresi paket disediakan melalui HTTP dari S3 dan CDN
  • Namun, infrastruktur GitHub tetap terbebani oleh repositori berukuran 83GB dan 20.000 fork
    • Pada November 2025, GitHub melaporkan kegagalan konsensus antar replika dan error pada pekerjaan pemeliharaan
    • Clone lokal berukuran 2,5GB, tetapi seluruh jaringan fork menekan kapasitas penyimpanan GitHub

vcpkg

  • Manajer paket C++ dari Microsoft, vcpkg, melakukan versioning dengan hash tree Git
    • Untuk mereproduksi port pada commit tertentu melalui builtin-baseline, seluruh riwayat diperlukan
  • Di lingkungan shallow clone (GitHub Actions, DevContainers), build dapat gagal
    • Solusinya memerlukan pengaturan fetch-depth: 0, yang berarti harus mengunduh seluruh riwayat
  • Karena struktur hash tree Git, pelacakan commit tidak dimungkinkan, dan keterbatasan ini tidak bisa diperbaiki secara struktural
  • Hingga kini, registry berbasis repositori Git masih menjadi satu-satunya yang didukung, tanpa alternatif HTTP atau CDN

Sistem modul Go

  • Tim engineering Grab melaporkan bahwa setelah modul proxy diperkenalkan, waktu go get berkurang dari 18 menit menjadi 12 detik
  • Pada cara lama, seluruh repositori dari setiap dependensi harus di-clone hanya untuk membaca go.mod
  • Tim Go mengkhawatirkan ketergantungan pada alat VCS dan celah keamanan
  • Mulai Go 1.13, GOPROXY menjadi default, menyediakan source modul dan go.mod melalui HTTP
    • sumdb (database checksum) menjamin integritas dan persistensi modul

Masalah umum saat Git digunakan sebagai database

  • Wiki berbasis Git (Gollum) menjadi lambat saat menelusuri direktori dan memuat halaman pada repositori besar
    • GitLab berencana menghentikan penggunaan Gollum
  • CMS berbasis Git (Decap) terbentur batas permintaan GitHub API (5.000 kali)
    • Di atas sekitar 10.000 item, performa menurun, dan pengguna baru dengan cache kosong memicu lonjakan permintaan
  • Alat GitOps (ArgoCD) mengalami masalah kehabisan ruang disk saat melakukan clone repositori
    • Satu commit dapat membatalkan seluruh cache, dan monorepo besar memerlukan scaling terpisah

Alasan struktural mengapa Git tidak cocok sebagai database

  • Batasan direktori: makin banyak file, makin lambat
    • CocoaPods menghasilkan objek tree yang sangat besar karena 16.000 direktori, dan ini diatasi dengan sharding berbasis hash
  • Masalah pembedaan huruf besar-kecil: Git membedakannya, tetapi macOS dan Windows tidak
    • Azure DevOps menambahkan fitur pemblokiran di sisi server untuk mencegah konflik
  • Batas panjang path: batas 260 karakter di Windows menyebabkan error pada git status
  • Ketiadaan fitur database:
    • Tidak ada constraint CHECK/UNIQUE, locking, indeks, maupun fitur migrasi
    • Setiap manajer paket harus membangun sendiri sistem validasi dan pengindeksannya

Kesimpulan

  • Git sangat unggul untuk kolaborasi source code, tetapi tidak cocok untuk kueri metadata paket atau pengelolaan registry berskala besar
  • Sebagian besar manajer paket pada akhirnya beralih ke indeks berbasis HTTP atau database
  • Keunggulan Git seperti riwayat versi dan workflow PR memang menarik, tetapi sebagai pengganti database ia gagal
  • Saat merancang manajer paket baru, meskipun indeks Git terlihat menarik, pada akhirnya akan mencapai batas yang sama seperti kasus Cargo, Homebrew, CocoaPods, vcpkg, dan Go

Bacaan terkait

2 komentar

 
lamanus 2025-12-28

Mereka memakainya karena git lebih praktis daripada harus membuat sistem terpisah untuk menerima kontribusi dari para kontributor. Ini disebut sebagai keterbatasan, tetapi saya pribadi tidak terlalu setuju, dan saya sama sekali tidak melihat alternatif untuk masalah yang realistis.
 
GN⁺ 2025-12-27
Komentar Hacker News

  • Ini terlihat seperti semacam tragedi milik bersama. GitHub gratis dan punya banyak fitur hebat, jadi semua orang ingin memakainya. Tapi keputusan seperti ini selalu muncul ketika ada eksternalitas
    Eksternalitas yang paling penting menurut saya adalah waktu pengguna. Kebanyakan perusahaan software hanya peduli pada biaya waktu engineering, dan mengabaikan waktu pengguna. Mereka bersemangat mengembangkan fitur, tetapi tidak mengoptimalkan waktu interaksi pengguna. Misalnya, jika saya menghabiskan 1 jam untuk membuat aplikasi 1 detik lebih cepat, satu juta pengguna akan menghemat 277 jam per tahun. Tetapi karena waktu pengguna adalah eksternalitas, optimasi seperti ini hampir tidak pernah dilakukan
    Pada akhirnya pengguna harus mengunduh lebih banyak data tanpa guna dan menunggu lebih lama, sementara pengembang tidak bertanggung jawab atas pemborosan itu

    • Saya tidak yakin tepatnya apa yang dimaksud dengan istilah “software house”, tetapi sebagian besar produk software konsumen yang pernah saya kerjakan melacak metrik seperti kecepatan startup atau latensi sebagai hal yang sangat penting. Ini sudah jadi pengetahuan umum sejak puluhan tahun lalu. Misalnya, kita juga sering mendengar bahwa Amazon kehilangan jutaan dolar hanya karena selisih beberapa milidetik waktu muat halaman
    • Ini sejalan dengan ungkapan “kecepatan juga merupakan sebuah fitur(feature) ”. Hanya saja, waktu pengguna sangat dipengaruhi bukan cuma oleh performa sederhana tetapi juga oleh desain UI
    • Saya rasa ini bukan “tragedi milik bersama”. GitHub dimiliki Microsoft, jadi mereka sendiri yang memutuskan bahwa mereka sanggup menanggungnya. Milik bersama yang sesungguhnya seharusnya tidak dimiliki siapa pun dan semua orang mendapat manfaat darinya
    • Kalau dipikirkan lebih dalam, saya teringat perkataan Alan Kay — “kalau benar-benar menganggap software itu penting, kamu juga harus membuat hardware sendiri”. Memuat sesuatu lewat jaringan pada dasarnya adalah pengalaman pengguna yang buruk. Kalau benar-benar menghormati pengguna, kita harus membuat aplikasi local-first(native-first). Tapi sangat sedikit perusahaan yang menghargai pengalaman pengguna sampai sejauh itu
    • Menarik juga membaca tulisan Andy Hertzfeld “Saving Lives” — ada kisah tentang “Booting Macintosh terlalu lambat. Kita harus membuatnya lebih cepat!”

  • Saya sedang membuat Cargo/UV untuk C. Tulisan yang bagus dan saya sangat berempati dengannya.
    Saat baru memulai, mengoperasikan registry itu benar-benar sulit. Bukan cuma soal menulis kode, menjaga kualitas tool, dan memperluas komunitas, tetapi juga harus memikirkan infrastruktur yang sanggup menangani trafik global. Dalam situasi seperti ini, solusi berbasis git memang menarik
    Tapi masalahnya adalah sparse checkout. Saya ingin versioning package manifest dengan git, tetapi karena harus melacak commit arbitrer, jadinya tidak efisien. Pada akhirnya strukturnya jadi harus push dua commit, jadi secara praktik tidak memungkinkan
    Saya rasa pendekatan Conan adalah yang paling praktis. Alih-alih reproduktibilitas sempurna, ia menaruh logika kondisional di manifest. Pemetaan manifest berdasarkan rentang versi juga dimungkinkan. Tidak sempurna, tetapi kompromi yang praktis dan berguna.
    Tentu saja solusi yang sebenarnya adalah memakai database, tetapi tidak ada yang akan membayari biaya server dan pemeliharaannya, jadi secara realistis sulit

    • Kalau dilihat dari sudut lain, sebagian besar package manager yang sukses pada awalnya mulai dari berbasis Git, lalu pindah ke struktur yang lebih efisien saat memang diperlukan
    • Pendekatan Arch Linux AUR juga layak dipertimbangkan. Setiap package punya repositori git independen dan hanya berisi manifest. Dengan begitu kita bisa menghindari masalah monorepo atau mimpi buruk referensi
    • Mengoperasikan registry dengan backend HTTP sederhana seperti S3 juga menarik. Di awal bisa mulai dari satu server, lalu kalau sudah populer cari sponsor dan pindah ke cloud.
      Jika masalahnya adalah uang dan kemandirian, pendekatan P2P juga memungkinkan. Hanya saja, kalau CI tidak bisa melakukan caching, trafik bisa meledak
    • Jika pengguna masih belum banyak, menyiapkan infrastruktur global dari awal adalah bentuk prematur
    • Tidak perlu menampilkan semua data histori kepada pengguna. Dengan post-commit hook, cukup render status HEAD menjadi file statis lalu sajikan seperti GitHub Pages.
      Struktur mirror distribusi Linux seperti Debian, Fedora, dan openSUSE juga layak dijadikan referensi

  • Tulisan ini mencampuradukkan dua masalah. Yang satu adalah memakai git sebagai database indeks package, yang lain adalah mengambil kode tiap package lewat git. Keduanya terpisah.
    Indeks bisa pakai git, package bisa pakai zip/tar, dan kebalikannya juga memungkinkan. Dalam kasus Go, strukturnya bahkan tanpa indeks sama sekali

    • Penulisnya tampak agak bingung. Saya setuju dengan argumen “jangan biarkan semua pengguna mereplikasi database”, tapi itu bukan berarti graf git tidak bisa dipakai untuk encoding data.
      Cerita tentang implementasi backend GitHub atau 20 ribu fork tidak relevan dengan esensinya. Bahkan tanpa git working tree pun, pencarian key-value yang efisien tetap memungkinkan.
      Klaim bahwa “rewrite histori git itu setara dengan migrasi DB” juga aneh. Memangnya tidak lebih baik jalankan saja satu Postgres?
    • Inti tulisan ini bukan pada kodenya sendiri, melainkan pada proses mengambil file go.mod. Karena itu solusinya adalah meng-host go.mod secara terpisah
    • Di git juga dimungkinkan untuk mengambil satu file saja yang dibutuhkan, tetapi secara struktur tetap terasa canggung

  • Pendekatan “pakai cara yang mudah saat masih bekerja, dan kalau nanti tidak bekerja baru diperbaiki” itu realistis.
    Julia juga memakai pendekatan yang sama, dan jumlah package-nya masih sekitar 1/7 dari Rust jadi belum ada masalah.
    Kita bisa memperbaikinya agar hanya mengambil file Registry.toml tingkat teratas lalu mengunduh package yang diperlukan saja. Bukan masalah besar

    • Julia memakai registry git hanya sebagai ledger resmi, sementara klien nyatanya menggunakan Pkg Protocol
    • Pendekatan ini juga bisa disebut semangat “FAFO(coba saja lalu hancur belakangan) ”. Memang praktis, tapi secara pribadi saya tidak menyukainya
    • Saya menganggap sikap seperti ini tidak etis. Pola pikir “buat dulu semudah mungkin, perbaiki belakangan” pada akhirnya hanya memperbesar utang teknis.
      Budaya “Move fast and break things” telah menghasilkan software masa kini yang lambat dan penuh bug
    • Jika masalah diperbaiki belakangan, biayanya meningkat secara eksponensial. Pada akhirnya kesimpulannya menjadi “ya sudah, pakai saja dalam keadaan agak rusak”. Dalam tulisan ini, kasus vcpkg adalah contohnya
    • Ada contoh yang tampaknya seperti seseorang memanipulasi UUID secara sengaja, dan agak mengkhawatirkan bahwa itu bisa dilakukan

  • Saya setuju dengan kesimpulan bahwa “Git adalah database yang sangat bagus untuk titik awal package manager”

    • Hanya saja, klien sebaiknya tidak menerima seluruh repositori, melainkan memakai lapisan cache atau DB. Dalam lingkungan CI/CD, efisiensi sangat penting
    • Nixpkgs juga berhasil berkat Git. Masalah skala adalah kemewahan untuk dipikirkan nanti
    • Tetapi sebelum terlalu memuja Git, ada baiknya setidaknya membaca sedikit tentang riset database
    • Git juga bisa memicu mimpi buruk rantai pasok. Insiden Leftpad bisa saja terulang setiap minggu
    • Git itu buruk sekali sebagai DB untuk package manager. Hanya saja semua orang memakainya karena GitHub meng-host-nya secara gratis

  • Saya berada di kubu “pada akhirnya toh berhasil”. Untuk operasi awal, itu cukup membantu, dan masalah skala bisa diselesaikan nanti

    • Tetapi beberapa proyek tidak bisa lepas dari git karena batasan arsitektural
    • Jika mulai dari store berbasis sistem file seperti git, nanti hampir mustahil mengganti protokol. Sejak awal harus memakai desain yang berpusat pada API
    • Justru masih ada peluang untuk memanfaatkan git dengan lebih efisien. Menyuruh meninggalkan git tanpa menawarkan alternatif adalah kesimpulan setengah matang
    • Ada juga lelucon sarkastik, “hanya karena tidak bisa scale dari 0 sampai 1 triliun pengguna lalu dibilang sampah”

  • Ada survivorship bias di sini. Cargo menjadi masalah karena sukses, sehingga indeks git-nya membesar.
    Sebagian besar proyek kecil menggunakan git dengan baik sebagai protokol distribusi data.
    Pada tahap awal ketika skala masih belum pasti, masuk akal memanfaatkan git dan GitHub agar bisa fokus pada masalah inti

    • Kita harus waspada terhadap optimasi yang terlalu dini. Cargo dan Homebrew juga tumbuh dengan memilih jalan yang mudah, dan masalah skala belakangan justru adalah “masalah yang bagus”

  • Setiap kali melihat tulisan di halaman depan HN yang mengatakan “apa yang sedang kamu lakukan sekarang itu salah”, saya jadi rendah hati.
    Saya juga pernah mengalami hal seperti itu beberapa kali. Kali ini yang seperti itu adalah tulisan tentang PG Notify.
    Tapi saat ini saya masih mengembangkan sendirian, bahkan belum tahu apakah proyek ini akan berhasil, jadi mendistribusikan plugin dengan git adalah pilihan yang paling realistis.
    Meski begitu, kalau nanti muncul masalah skala, saya akan merujuk ke tulisan ini

    • Bahkan sekarang pun ada beberapa jebakan yang bisa dihindari. Vendor lock-in seperti ketergantungan pada GitHub mungkin justru masalah yang lebih besar

  • Saya pribadi meng-host kode dengan Forgejo. Saya melindunginya dengan mTLS tanpa eksposur ke luar.
    Tapi modul Go membutuhkan sertifikat sehingga tidak bisa mengenali instance Forgejo saya.
    Bahkan kalau memakai SSH pun tetap perlu akses HTTPS, jadi akhirnya saya memakai salinan lokal lewat replace directive. Cukup merepotkan

    • Jika menambahkan .git di akhir path modul dan mengatur $GOPRIVATE, Anda bisa memakai autentikasi perintah git tanpa permintaan HTTPS. Lihat dokumentasi resmi
    • Jika sertifikat TLS(CA) instance ditambahkan ke trust store, unduhan HTTPS juga dimungkinkan
    • Pernyataan bahwa “akses HTTP diperlukan” sebenarnya tidak benar. Proxy lokal bisa menyelesaikannya
    • Dengan DNS dan sertifikat Tailscale, Anda bisa mendapatkan sertifikat Let’s Encrypt tanpa eksposur ke luar

  • Bukan hanya package manager, banyak proyek kecil juga melakukan crowdsourcing data ke dalam repositori git.
    Sebagian besar skalanya kecil, jadi tidak pernah menabrak batas teknis.
    Tetapi struktur seperti ini meningkatkan hambatan partisipasi bagi non-pengembang. Package manager adalah pengecualian, tetapi untuk proyek umum ini menjadi masalah
    Untuk membantu masalah seperti ini, saya membuat library open source bernama Datatig.
    Materi presentasi terkait ada di sini. Ke depannya saya akan merujuk tulisan ini dan menambahkan konten terkait scaling juga.