Paketmanager, die Git als Datenbank verwenden, scheitern am Ende

(nesbitt.io)

7 Punkte von GN⁺ 2025-12-27 | Noch keine Kommentare. | Auf WhatsApp teilen

Mehrere Paketmanager nutzten Git wie eine Datenbank, weil Versionsverwaltung und Zusammenarbeit bequem sind, stießen mit wachsender Größe jedoch auf Performance- und Wartungsprobleme
Cargo, Homebrew und CocoaPods wechselten schließlich wegen der wachsenden Größe ihrer Git-Indizes, langsamer Updates und Ineffizienz in CI-Umgebungen zu HTTP-basierten Indizes oder CDNs
vcpkg arbeitet weiterhin auf Basis von Git-Tree-Hashes; in Umgebungen mit flachen Klonen (shallow clone) kommt es zu Build-Fehlschlägen und komplizierten Workarounds
Das Go-Modulsystem führte GOPROXY und eine Prüfsummendatenbank (sumdb) ein, entfernte damit die Git-Abhängigkeit und verbesserte Sicherheit und Geschwindigkeit
Git ist für die Zusammenarbeit an Code hervorragend geeignet, erweist sich jedoch immer wieder als ungeeignet für Paket-Metadatenabfragen oder die Verwaltung großer Register

Das wiederholte Scheitern von Versuchen, Git als Datenbank zu verwenden

Git ist wegen Vorteilen wie Versionshistorie, verteilter Struktur und kostenlosem Hosting attraktiv, stößt als Datenbank aber an Skalierungsgrenzen
Mehrere Paketmanager übernahmen Git als Index, doch mit der Zeit nahmen Leistungseinbußen und Infrastrukturbelastung zu

Der crates.io-Index begann als Git-Repository, und alle Clients führten eine vollständige Replikation (clone) durch
- Als das Repository wuchs, entstand in der Delta-Resolution-Phase ein Performance-Flaschenhals in libgit2
- In CI-Umgebungen wurde bei jedem Build der komplette Index heruntergeladen, was zu erheblicher Verschwendung führte
Mit RFC 2789 wurde das sparse-HTTP-Protokoll eingeführt, sodass nur die benötigten Metadaten per HTTPS abgerufen werden
- Stand April 2025 nutzen 99 % der Anfragen den sparse-Modus
- Der Git-Index existiert weiterhin, wird von den meisten Nutzern aber nicht mehr verwendet

GitHub bat Homebrew darum, keine flachen Klone mehr zu verwenden; Updates wurden als „sehr teure Operation“ bezeichnet
- Der .git-Ordner von homebrew-core nähert sich 1 GB, und bei Updates kommt es durch Delta Resolution zu Verzögerungen
Im Februar 2023 stellte Homebrew 4.0.0 Tap-Updates auf einen JSON-Download-Mechanismus um
- Durch den Wegfall von Git fetch wurden Updates schneller, und der automatische Update-Zyklus änderte sich von 5 Minuten auf 24 Stunden

Beim Paketmanager CocoaPods für iOS/macOS wurde das aus Hunderttausenden podspecs bestehende Specs-Repository übermäßig groß
- Klonen und Aktualisieren dauerten mehrere Minuten, und der Großteil der CI-Zeit ging für Git-Operationen drauf
GitHub führte ein CPU-Rate-Limit ein; flache Klone wurden als Ursache der Serverlast benannt
Das Team setzte Übergangsmaßnahmen wie das Abschalten automatischer Fetches, den Wechsel zu vollständigen Klonen und das Sharding des Repositorys um
Ab Version 1.8 erfolgte der Wechsel zu CDN-basierter HTTP-Auslieferung, wodurch bei Nutzern etwa 1 GB Speicherplatz eingespart und die Installationsgeschwindigkeit deutlich verbessert wurde

Nix vermeidet auf Client-Seite bereits Git-Klone durch tarball-basierte Channels
- Paketausdrücke werden per HTTP über S3 und CDN bereitgestellt
Die Infrastruktur von GitHub wird jedoch durch ein 83-GB-Repository und 20.000 Forks belastet
- Im November 2025 meldete GitHub fehlgeschlagene Einigungen zwischen Replikaten und Fehler bei Wartungsarbeiten
- Lokale Klone sind zwar 2,5 GB groß, aber das gesamte Fork-Netzwerk belastet den GitHub-Speicher stark

vcpkg, der C++-Paketmanager von Microsoft, versioniert mit Git-Tree-Hashes
- Um über builtin-baseline die Ports eines bestimmten Commit-Zeitpunkts reproduzieren zu können, wird die vollständige Historie benötigt
In Umgebungen mit flachen Klonen (GitHub Actions, DevContainers) schlagen Builds fehl
- Als Lösung ist die Einstellung fetch-depth: 0 nötig, was den Download der gesamten Historie erfordert
Aufgrund der Struktur von Git-Tree-Hashes ist kein Commit-Tracking möglich; das Problem ist wegen struktureller Grenzen nicht behebbar
Unterstützt werden weiterhin nur registerbasierte Git-Repositories, HTTP- oder CDN-Alternativen gibt es nicht

Das Engineering-Team von Grab verkürzte nach Einführung eines Modul-Proxys die Zeit für go get von 18 Minuten auf 12 Sekunden
Im bisherigen Verfahren musste das gesamte Repository jeder Abhängigkeit geklont werden, um go.mod lesen zu können
Das Go-Team hatte Bedenken wegen der Abhängigkeit von VCS-Werkzeugen und Sicherheitslücken
Seit Go 1.13 ist GOPROXY der Standard; Modulquellen und go.mod werden per HTTP bereitgestellt
- sumdb (Prüfsummendatenbank) gewährleistet Integrität und Dauerhaftigkeit der Module

Git-basiertes Wiki (Gollum) wird bei großen Repositories bei der Verzeichnisnavigation und beim Laden von Seiten langsam
- GitLab plant, die Nutzung von Gollum einzustellen
Git-basiertes CMS (Decap) stößt an das GitHub-API-Limit von 5.000 Anfragen
- Ab etwa 10.000 Einträgen sinkt die Leistung, und neue Nutzer mit leerem Cache verursachen eine Anfragenflut
GitOps-Tool (ArgoCD) hat beim Klonen von Repositories Probleme mit überschrittenem Speicherplatz
- Ein einzelner Commit invalidiert den gesamten Cache, und große Monorepos benötigen gesonderte Skalierung

Verzeichnisgrenzen: Mit steigender Dateizahl wird Git langsamer
- CocoaPods erzeugte wegen 16.000 Verzeichnissen riesige Tree-Objekte und löste das Problem durch hashbasiertes Sharding
Groß-/Kleinschreibung: Git unterscheidet sie, macOS und Windows jedoch nicht
- Azure DevOps ergänzte serverseitige Sperren, um Konflikte zu verhindern
Beschränkung der Pfadlänge: Das Windows-Limit von 260 Zeichen verursacht Fehler bei git status
Fehlende Datenbankfunktionen:
- Es gibt keine CHECK-/UNIQUE-Constraints, keine Sperren, keine Indizes und keine Migrationsfunktionen
- Jeder Paketmanager muss eigene Systeme für Validierung und Indizierung aufbauen

Git ist für die Zusammenarbeit an Quellcode hervorragend geeignet, jedoch ungeeignet für Paket-Metadatenabfragen oder die Verwaltung großer Register
Die meisten Paketmanager wechseln am Ende zu HTTP-basierten Indizes oder Datenbanken
Die Vorteile von Git (Versionshistorie, PR-Workflow) sind attraktiv, doch als Datenbankersatz scheitert es
Auch wenn ein Git-Index beim Entwurf eines neuen Paketmanagers attraktiv wirkt, stößt man wie bei Cargo, Homebrew, CocoaPods, vcpkg und Go auf dieselben Grenzen