Git को डेटाबेस की तरह इस्तेमाल करने वाले पैकेज मैनेजर आखिरकार असफल होते हैं

 (nesbitt.io)
7 पॉइंट द्वारा GN⁺ 2025-12-27 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • कई package managers ने version control और collaboration की सुविधा के कारण Git को डेटाबेस की तरह इस्तेमाल किया, लेकिन scale बढ़ने पर performance और maintenance की समस्याओं से टकराए
  • Cargo, Homebrew, CocoaPods आदि ने Git index के आकार में वृद्धि, धीमे update, और CI environments की अक्षमता के कारण आखिरकार HTTP-आधारित index या CDN अपनाए
  • vcpkg अब भी Git tree hash पर आधारित है, और shallow clone environment में build failures और जटिल workaround पैदा होते हैं
  • Go module system ने GOPROXY और checksum database (sumdb) अपनाकर Git dependency हटाई और security व speed बेहतर की
  • Git code collaboration के लिए बेहतरीन है, लेकिन package metadata queries या बड़े registry management के लिए उपयुक्त नहीं है — यह बात बार-बार सामने आई है

Git को डेटाबेस की तरह इस्तेमाल करने की बार-बार असफल कोशिश

  • Git के version history, distributed structure, और free hosting जैसे फायदे इसे आकर्षक बनाते हैं, लेकिन डेटाबेस की तरह इस्तेमाल करने पर यह scalability limits से टकराता है
  • कई package managers ने Git को index के रूप में अपनाया, लेकिन समय के साथ performance degradation और infrastructure burden बढ़ता गया

Cargo

  • crates.io index की शुरुआत Git repository के रूप में हुई थी, और सभी clients पूरा clone करते थे
    • repository के बड़ा होने पर delta resolution चरण में libgit2 का performance bottleneck सामने आया
    • CI environments में हर build पर पूरा index डाउनलोड होता था, जिससे भारी बर्बादी होती थी
  • RFC 2789 के जरिए sparse HTTP protocol लाया गया, ताकि केवल जरूरी metadata ही HTTPS से लिया जाए
    • अप्रैल 2025 तक 99% requests sparse mode का इस्तेमाल कर रही थीं
    • Git index अब भी मौजूद है, लेकिन ज्यादातर users उसे access नहीं करते

Homebrew

  • GitHub ने Homebrew से shallow clone का उपयोग बंद करने को कहा, और update को “बेहद महंगा operation” बताया
    • homebrew-core का .git folder लगभग 1GB तक पहुंच गया, और update के समय delta resolution से देरी होती थी
  • फ़रवरी 2023 में Homebrew 4.0.0 ने tap updates को JSON download model में बदल दिया
    • Git fetch हटने से update speed बढ़ी, और auto-update cycle भी 5 मिनट से 24 घंटे कर दी गई

CocoaPods

  • iOS/macOS के package manager CocoaPods का Specs repository, जिसमें लाखों podspecs थे, बहुत बड़ा हो गया
    • clone और update में कई मिनट लगते थे, और CI time का बड़ा हिस्सा Git operations में खर्च होता था
  • GitHub ने CPU rate limit लगाया, और shallow clone को server load का कारण बताया
  • टीम ने automatic fetch बंद करना, full clone पर जाना, repository sharding जैसी अस्थायी कार्रवाइयाँ कीं
  • version 1.8 से CDN-आधारित HTTP distribution अपनाया गया, जिससे users का लगभग 1GB disk space बचा और install speed काफी बेहतर हुई

Nixpkgs

  • Nix client side पर पहले से ही tarball-based channels इस्तेमाल करता है, ताकि Git clone से बचा जा सके
    • package expressions को S3 और CDN से HTTP पर serve किया जाता है
  • लेकिन GitHub की infrastructure पर 83GB repository और 20,000 forks का बोझ पड़ा
    • नवंबर 2025 में GitHub ने replica consensus failures और maintenance task errors की रिपोर्ट दी
    • local clone 2.5GB का है, लेकिन पूरा fork network GitHub storage पर दबाव डालता है

vcpkg

  • Microsoft का C++ package manager vcpkg Git tree hash से versioning करता है
    • builtin-baseline के जरिए किसी खास commit point के ports दोहराने के लिए पूरा history चाहिए
  • shallow clone environments (GitHub Actions, DevContainers) में build failures होते हैं
    • समाधान के रूप में fetch-depth: 0 सेट करना पड़ता है, यानी पूरा history डाउनलोड करना पड़ता है
  • Git tree hash structure के कारण commit tracking संभव नहीं, और यह structural limitation आसानी से सुधारी नहीं जा सकती
  • अब भी केवल Git repository-based registry ही supported है, HTTP या CDN alternative नहीं है

Go module system

  • Grab engineering team ने module proxy अपनाने के बाद go get समय 18 मिनट → 12 सेकंड कर दिया
  • पुराने तरीके में हर dependency का पूरा repository clone करना पड़ता था, ताकि go.mod पढ़ा जा सके
  • Go team को VCS tool dependencies और security vulnerabilities की चिंता थी
  • Go 1.13 से GOPROXY default बना, जो module source और go.mod को HTTP पर serve करता है
    • sumdb (checksum database) module integrity और persistence सुनिश्चित करता है

Git को डेटाबेस की तरह इस्तेमाल करने पर आम समस्याएँ

  • Git-based wiki (Gollum) में बड़े repositories पर directory browsing और page loading धीमे हो जाते हैं
    • GitLab, Gollum का उपयोग बंद करने की योजना बना रहा है
  • Git-based CMS (Decap), GitHub API request limit (5,000) से टकराता है
    • लगभग 10,000 से अधिक items पर performance गिरती है, और empty cache वाले नए users request storm पैदा करते हैं
  • GitOps tool (ArgoCD) में repository clone के समय disk space limit पार हो जाती है
    • एक ही commit पूरा cache invalid कर सकता है, और बड़े monorepo के लिए अलग scaling चाहिए

Git डेटाबेस के रूप में संरचनात्मक रूप से क्यों अनुपयुक्त है

  • directory limit: files की संख्या बढ़ने पर performance गिरती है
    • CocoaPods में 16,000 directories के कारण बहुत बड़े tree objects बने, जिन्हें hash-based sharding से संभाला गया
  • case sensitivity issue: Git case-sensitive है, लेकिन macOS और Windows नहीं
    • Azure DevOps ने conflicts रोकने के लिए server-side blocking feature जोड़ा
  • path length limit: Windows की 260-character limit से git status errors आते हैं
  • database features की कमी:
    • CHECK/UNIQUE constraints, locking, indexing, migration — कुछ भी मौजूद नहीं
    • हर package manager को अपना validation और indexing system खुद बनाना पड़ता है

निष्कर्ष

  • Git source code collaboration के लिए बेहतरीन है, लेकिन package metadata queries या बड़े registry management के लिए उपयुक्त नहीं
  • ज्यादातर package managers आखिरकार HTTP-आधारित index या database की ओर चले गए
  • Git के फायदे — version history और PR workflow — आकर्षक हैं, लेकिन database replacement के रूप में यह असफल रहा
  • नया package manager design करते समय Git index आकर्षक लग सकता है, लेकिन Cargo·Homebrew·CocoaPods·vcpkg·Go के उदाहरणों की तरह वही सीमाएँ अंततः सामने आती हैं

संबंधित पढ़ाई

2 टिप्पणियां

 
GN⁺ 2025-12-27
Hacker News की राय

  • यह कुछ हद तक tragedy of the commons जैसा लगता है। GitHub मुफ़्त है और उसमें बहुत-सी शानदार सुविधाएँ हैं, इसलिए हर कोई उसका इस्तेमाल करना चाहता है। लेकिन जब externalities होती हैं, तब ऐसे फ़ैसले हमेशा होते हैं
    मेरे हिसाब से सबसे महत्वपूर्ण externality है यूज़र का समय। ज़्यादातर software कंपनियाँ सिर्फ engineering time की लागत देखती हैं और यूज़र के समय को नज़रअंदाज़ करती हैं। वे feature development पर ध्यान देती हैं, लेकिन user interaction time को optimize नहीं करतीं। उदाहरण के लिए, अगर मैं किसी app को 1 सेकंड तेज़ बनाने में 1 घंटा लगाऊँ, तो 10 लाख यूज़र मिलकर हर साल 277 घंटे बचाते हैं। लेकिन यूज़र का समय एक externality है, इसलिए ऐसी optimization बहुत कम होती है
    आख़िरकार यूज़र बेकार में ज़्यादा data download करते हैं और इंतज़ार करते हैं, और developer इस बर्बादी के लिए ज़िम्मेदारी नहीं लेते

    • “software house” से ठीक-ठीक क्या मतलब है, यह मुझे नहीं पता, लेकिन जिन ज़्यादातर consumer software products पर मैंने काम किया है, उनमें startup speed और latency जैसे metrics को मुख्य रूप से track किया जाता था। यह तो दशकों से सामान्य समझ का हिस्सा रहा है। उदाहरण के लिए, Amazon के बारे में यह बात अक्सर सुनने को मिलती थी कि page loading में कुछ milliseconds का फ़र्क उन्हें लाखों डॉलर का नुकसान करा सकता है
    • यह उसी संदर्भ की बात है कि “speed भी एक feature है।” बस यूज़र का समय सिर्फ performance नहीं, बल्कि UI design से भी बहुत प्रभावित होता है
    • मुझे नहीं लगता कि यह “tragedy of the commons” है। GitHub Microsoft के स्वामित्व में है, इसलिए उन्होंने तय किया है कि वे इसका बोझ उठा सकते हैं। असली commons ऐसी चीज़ होनी चाहिए जिसका मालिक कोई न हो और जिससे सबको लाभ मिले
    • इस समस्या पर गहराई से सोचने पर Alan Kay की बात याद आती है — “अगर आप सच में software को गंभीरता से लेते हैं, तो hardware भी खुद बनाना चाहिए।” नेटवर्क पर लोडिंग मूल रूप से ख़राब user experience है। अगर आप सच में यूज़र्स का सम्मान करते हैं, तो आपको local-first (native-first) applications बनानी चाहिए। लेकिन इतनी हद तक user experience का सम्मान करने वाली कंपनियाँ बहुत कम हैं
    • Andy Hertzfeld का लेख “Saving Lives” दिलचस्प है — उसमें “Macintosh बहुत धीरे boot होता है। इसे तेज़ बनाना होगा!” वाली घटना है

  • मैं C के लिए Cargo/UV बना रहा हूँ। यह बढ़िया लेख है और मैं इससे गहराई से सहमत हूँ।
    शुरुआत करते समय registry चलाना सच में बहुत मुश्किल काम है। सिर्फ code लिखना, tool की quality सुनिश्चित करना और community फैलाना ही नहीं, बल्कि दुनिया भर के traffic को संभालने वाली infrastructure के बारे में भी सोचना पड़ता है। ऐसे में git-आधारित solution आकर्षक लगता है
    लेकिन समस्या sparse checkout है। मैं package manifests को git में version-control करना चाहता हूँ, लेकिन arbitrary commits को track करना पड़ता है, इसलिए यह अक्षम है। आख़िरकार ढाँचा ऐसा बनता है कि दो बार commits push करने पड़ते हैं, इसलिए व्यवहार में यह संभव नहीं है
    मुझे लगता है Conan का approach सबसे व्यावहारिक है। पूर्ण reproducibility की जगह manifest में conditional logic डालने का तरीका। version ranges के हिसाब से manifest mapping भी संभव है। यह परफ़ेक्ट नहीं है, लेकिन व्यावहारिक और उपयोगी समझौता है।
    बेशक असली समाधान database का इस्तेमाल करना है, लेकिन server cost और maintenance cost कोई और भरने वाला नहीं है, इसलिए यह व्यवहार में मुश्किल है

    • नज़रिये को बदलकर देखें तो, ज़्यादातर सफल package managers ने शुरुआत Git-आधारित रूप में की थी और ज़रूरत पड़ने पर बाद में अधिक कुशल संरचना की ओर गए
    • Arch Linux AUR का तरीका भी विचार करने लायक है। हर package का अपना अलग git repository हो, जिसमें सिर्फ manifest हो। इससे monorepo problem और reference nightmare से बचा जा सकता है
    • S3 जैसे साधारण HTTP backend पर repository चलाना भी आकर्षक है। शुरुआत में एक single server से शुरू करें, और लोकप्रियता बढ़ने पर sponsor ढूँढकर cloud पर ले जाएँ।
      अगर पैसा और स्वतंत्रता समस्या है, तो P2P तरीका भी संभव है। बस अगर CI caching न हो, तो traffic तेज़ी से बढ़ सकता है
    • अगर अभी यूज़र ज़्यादा नहीं हैं, तो पूरी दुनिया के लिए infrastructure पहले से तैयार करना premature है
    • ज़रूरी नहीं कि सारी history data यूज़र्स को दिखाई जाए। post-commit hook से सिर्फ HEAD state को static files में render करके GitHub Pages की तरह serve किया जा सकता है।
      Debian, Fedora, openSUSE जैसी Linux distributions की mirror structure भी संदर्भ के लिए उपयोगी है

  • यह लेख दो समस्याओं को मिला रहा है। एक है git को package index database की तरह इस्तेमाल करना, और दूसरी है हर package का code git से लाना। ये दोनों अलग बातें हैं।
    index को git में और packages को zip/tar में रखा जा सकता है, या इसका उल्टा भी संभव है। Go के मामले में तो index होता ही नहीं

    • लेखक थोड़ा भ्रमित लगता है। “हर यूज़र को database की copy नहीं करनी चाहिए” वाली बात से मैं सहमत हूँ, लेकिन इसका मतलब यह नहीं कि data encoding के लिए git graph का इस्तेमाल नहीं किया जा सकता।
      GitHub के backend implementation या 20,000 forks जैसी बातें मूल मुद्दे से जुड़ी नहीं हैं। git working tree के बिना भी कुशल key-value lookup संभव है।
      “git history rewrite, DB migration जैसा है” वाली बात भी अजीब है। इससे तो एक Postgres चलाना बेहतर नहीं होगा?
    • लेख का असली बिंदु code ख़ुद नहीं, बल्कि go.mod file लाने की प्रक्रिया है। इसलिए समाधान के तौर पर go.mod को अलग से host किया गया
    • git में भी ज़रूरी single file लाना संभव है, लेकिन फिर भी संरचनात्मक रूप से यह अटपटा है

  • “जब तक काम चल रहा है, आसान तरीका अपनाओ; जब समस्या आए, तब ठीक करो” वाला approach व्यावहारिक है।
    Julia भी यही तरीका अपनाती है, और उसके packages Rust की तुलना में सिर्फ 1/7 हैं, इसलिए अभी समस्या नहीं है।
    सिर्फ सबसे ऊपर की Registry.toml file लेकर ज़रूरी packages ही download करने के लिए इसे सुधारा जा सकता है। यह कोई बड़ी समस्या नहीं है

    • Julia git registry का इस्तेमाल सिर्फ official ledger के रूप में करती है, जबकि असली client Pkg Protocol का उपयोग करता है
    • इस approach को “FAFO(करके देखो और भुगतो)” मानसिकता भी कहा जा सकता है। यह व्यावहारिक है, लेकिन मुझे व्यक्तिगत रूप से पसंद नहीं
    • मुझे लगता है कि यह रवैया अनैतिक है। “पहले आसानी से बना लो, बाद में ठीक कर लेंगे” वाली सोच अंततः technical debt बढ़ाती है।
      “Move fast and break things” संस्कृति का नतीजा ही आज का धीमा और bugs से भरा software है
    • अगर समस्या बाद में ठीक की जाए, तो लागत घातीय रूप से बढ़ती है। आख़िरकार नतीजा “थोड़ा टूटा है, फिर भी इस्तेमाल करो” जैसा होता है। लेख में vcpkg का मामला उसी का उदाहरण है
    • एक उदाहरण ऐसा है जिसमें लगता है कि किसी ने UUID को जानबूझकर छेड़ा है, और यह संभव होना थोड़ा चिंताजनक है

  • मैं इस निष्कर्ष से सहमत हूँ कि “Git package manager की शुरुआत के लिए बेहतरीन database है”

    • बस client को पूरा repository नहीं लेना चाहिए; उसकी जगह cache या DB layer रखना बेहतर है। खासकर CI/CD environments में efficiency बहुत महत्वपूर्ण है
    • Nixpkgs भी Git की वजह से सफल हुआ। scale की समस्या बाद की विलासितापूर्ण चिंता है
    • लेकिन Git की तारीफ़ करने से पहले database research पर थोड़ा नज़र डालना अच्छा होगा
    • Git supply chain nightmare भी पैदा कर सकता है। Leftpad incident हर हफ़्ते दोहराया जा सकता है
    • Git package manager के DB के रूप में बेहद ख़राब है। लोग सिर्फ इसलिए इसका इस्तेमाल करते हैं क्योंकि GitHub इसे मुफ़्त में host करता है

  • मेरा रुख़ “आख़िरकार यह काम कर गया, है न?” वाला है। शुरुआती संचालन में इसने काफ़ी मदद की और scale की समस्या बाद में सुलझाई जा सकी

    • लेकिन कुछ projects architectural limitations की वजह से git से बाहर नहीं निकल पा रहे हैं
    • अगर आप git जैसी filesystem-based store से शुरुआत करते हैं, तो बाद में protocol बदलना लगभग असंभव हो जाता है। शुरुआत से API-centric design अपनानी चाहिए
    • बल्कि git का और अधिक कुशल इस्तेमाल करने का मौका है। कोई विकल्प दिए बिना git छोड़ने को कहना आधा-अधूरा निष्कर्ष है
    • एक व्यंग्यात्मक मज़ाक भी है: “0 से 1 ट्रिलियन यूज़र्स तक scale नहीं हुआ, इसलिए यह कचरा है”

  • यहाँ survivorship bias है। Cargo सफल हुआ, इसलिए git index बड़ा हो गया और समस्या बनी।
    ज़्यादातर छोटे projects आज भी git को data distribution protocol की तरह अच्छी तरह इस्तेमाल कर रहे हैं।
    शुरुआत में, जब scale अनिश्चित हो, git और GitHub का इस्तेमाल करके मुख्य समस्या पर ध्यान केंद्रित करना तर्कसंगत है

    • बहुत जल्दी optimization करने से बचना चाहिए। Cargo और Homebrew ने भी आसान रास्ता चुना और बढ़े; scale की समस्या बाद में आने वाली “अच्छी समस्या” थी

  • HN के पहले पेज पर जब भी “जो तुम अभी कर रहे हो, वह ग़लत है” जैसा लेख दिखता है, मैं हमेशा विनम्र हो जाता हूँ।
    मेरे साथ भी ऐसा कुछ बार हुआ है। इस बार PG Notify पर लेख ऐसा था।
    लेकिन अभी मैं अकेले development कर रहा हूँ, और मुझे यह भी नहीं पता कि project सफल होगा या नहीं, इसलिए git से plugin distribution करना सबसे व्यावहारिक विकल्प है।
    फिर भी अगर बाद में scale की समस्या आती है, तो मैं इस लेख को संदर्भ के रूप में देखूँगा

    • अभी भी कुछ pitfalls से बचा जा सकता है। GitHub पर निर्भरता जैसा vendor lock-in शायद और बड़ी समस्या हो सकता है

  • मैं व्यक्तिगत रूप से Forgejo पर code host करता हूँ। बाहर से public exposure के बिना, इसे mTLS से सुरक्षित रखता हूँ।
    लेकिन Go modules certificates की माँग करते हैं, इसलिए वे मेरे Forgejo instance को पहचान नहीं पाते।
    SSH इस्तेमाल करने पर भी HTTPS access चाहिए, ऐसा कहा गया, इसलिए आख़िरकार मैंने replace directive के साथ local replica इस्तेमाल किया। काफ़ी झंझट है

    • अगर module path के अंत में .git जोड़ दें और $GOPRIVATE सेट करें, तो HTTPS request के बिना git command authentication इस्तेमाल किया जा सकता है। आधिकारिक दस्तावेज़ देखें
    • instance के TLS certificate (CA) को trust store में जोड़ दें, तो HTTPS download भी संभव है
    • “HTTP access चाहिए” वाली बात वास्तव में सही नहीं है। local proxy से इसका समाधान हो सकता है
    • Tailscale DNS और certificates का इस्तेमाल करें, तो public exposure के बिना Let’s Encrypt certificate लिया जा सकता है

  • सिर्फ package managers ही नहीं, बहुत-से छोटे projects भी data को git repositories में crowdsource करते हैं।
    ज़्यादातर का पैमाना छोटा होता है, इसलिए वे तकनीकी सीमाओं से नहीं टकराते।
    लेकिन ऐसी संरचना non-developers की भागीदारी की बाधा बढ़ाती है। package managers अपवाद हो सकते हैं, लेकिन सामान्य projects के लिए यह समस्या है
    इस तरह की समस्या में मदद के लिए मैंने Datatig नाम की एक open source library बनाई है।
    संबंधित प्रस्तुति सामग्री यहाँ है। आगे मैं इस लेख को संदर्भ में रखते हुए scaling से जुड़ी सामग्री भी जोड़ने वाला हूँ
 
lamanus 2025-12-28

contributors से योगदान लेने के लिए अलग से सिस्टम बनाने के बजाय Git आसान है, इसलिए उसका इस्तेमाल करते हैं। इसे सीमा कहा जा रहा है, लेकिन उससे मैं खास सहमत नहीं हूँ, और वास्तविक समस्याओं के लिए कोई व्यावहारिक विकल्प भी बिल्कुल नहीं दिख रहा।