- Plusieurs gestionnaires de paquets ont utilisé Git comme une base de données pour profiter de la gestion de versions et de la collaboration, mais à mesure que l’échelle augmente, ils se heurtent à des problèmes de performances et de maintenance
- Cargo, Homebrew et CocoaPods, entre autres, ont finalement migré vers des index basés sur HTTP ou des CDN en raison de la croissance de la taille des index Git, de la lenteur des mises à jour et de l’inefficacité dans les environnements CI
- vcpkg continue de fonctionner sur la base de hachages d’arbres Git, ce qui provoque des échecs de build et des contournements complexes dans les environnements en shallow clone
- Le système de modules Go a introduit GOPROXY et une base de données de sommes de contrôle (sumdb) afin d’éliminer la dépendance à Git et d’améliorer la sécurité comme la vitesse
- Git est excellent pour la collaboration sur le code, mais il apparaît de façon répétée qu’il est mal adapté aux requêtes sur les métadonnées de paquets et à la gestion de registres à grande échelle
Les échecs répétés des tentatives d’utiliser Git comme base de données
- Git est attractif grâce à ses avantages comme l’historique des versions, l’architecture distribuée et l’hébergement gratuit, mais son utilisation comme base de données se heurte à des limites de montée en charge
- Plusieurs gestionnaires de paquets ont adopté Git comme index, mais avec le temps les dégradations de performances et la charge d’infrastructure se sont aggravées
Cargo
- L’index de crates.io a commencé comme un dépôt Git, et tous les clients effectuaient un clone complet
- À mesure que le dépôt grossissait, un goulot d’étranglement de performance dans libgit2 est apparu pendant l’étape de delta resolution
- Dans les environnements CI, l’index complet était téléchargé à chaque build, entraînant un gaspillage important
- Via la RFC 2789, le protocole sparse HTTP a été introduit afin de ne récupérer via HTTPS que les métadonnées nécessaires
- En avril 2025, 99 % des requêtes utilisent le mode sparse
- L’index Git existe toujours, mais la majorité des utilisateurs n’y accèdent plus
Homebrew
- GitHub a demandé à Homebrew de cesser d’utiliser les shallow clones, en signalant que les mises à jour étaient des « opérations très coûteuses »
- Le dossier
.git de homebrew-core approche 1 Go, et les mises à jour subissent des lenteurs liées à la delta resolution
- En février 2023, avec Homebrew 4.0.0, la mise à jour des taps a basculé vers un téléchargement au format JSON
- La suppression de
git fetch a accéléré les mises à jour, et la fréquence des mises à jour automatiques est passée de 5 minutes à 24 heures
CocoaPods
- Le gestionnaire de paquets CocoaPods pour iOS/macOS a vu son dépôt Specs, composé de plusieurs centaines de milliers de podspecs, devenir excessivement volumineux
- Le clonage et les mises à jour prenaient plusieurs minutes, et l’essentiel du temps CI était consommé par les opérations Git
- GitHub a appliqué une CPU rate limit, en désignant les shallow clones comme cause de la charge serveur
- L’équipe a mis en place des mesures temporaires comme l’arrêt des fetch automatiques, le passage au clone complet et le sharding du dépôt
- À partir de la version 1.8, le projet est passé à une distribution HTTP basée sur CDN, économisant environ 1 Go d’espace disque côté utilisateur et améliorant fortement la vitesse d’installation
Nixpkgs
- Nix évite déjà le clonage Git côté client en utilisant des channels basés sur des tarballs
- Les expressions de paquets sont fournies en HTTP depuis S3 et un CDN
- Cependant, l’infrastructure de GitHub est sous pression à cause d’un dépôt de 83 Go et de 20 000 forks
- En novembre 2025, GitHub a signalé des échecs de consensus entre réplicas et des erreurs lors des opérations de maintenance
- Le clone local fait 2,5 Go, mais l’ensemble du réseau de forks exerce une pression sur l’espace de stockage de GitHub
vcpkg
- Le gestionnaire de paquets C++ de Microsoft, vcpkg, utilise des hachages d’arbres Git pour le versionnement
- Avec
builtin-baseline, il faut l’historique complet pour reproduire les ports à un commit donné
- Dans les environnements en shallow clone (GitHub Actions, DevContainers), cela provoque des échecs de build
- La solution consiste à définir
fetch-depth: 0, ce qui impose le téléchargement de l’historique complet
- En raison de la structure des hachages d’arbres Git, le suivi des commits est impossible, et cette limite structurelle ne peut pas être corrigée
- Le projet ne prend toujours en charge que des registres basés sur des dépôts Git, sans alternative HTTP ni CDN
Système de modules Go
- L’équipe d’ingénierie de Grab a réduit le temps de
go get de 18 minutes à 12 secondes après l’introduction d’un proxy de modules
- L’ancienne méthode obligeait à cloner le dépôt complet de chaque dépendance pour pouvoir lire
go.mod
- L’équipe Go s’inquiétait de la dépendance aux outils VCS et des vulnérabilités de sécurité
- Depuis Go 1.13, GOPROXY est la valeur par défaut, et les sources des modules ainsi que
go.mod sont fournis en HTTP
- sumdb (base de données de sommes de contrôle) garantit l’intégrité et la pérennité des modules
Problèmes généraux quand Git est utilisé comme base de données
- Le wiki basé sur Git (Gollum) devient lent pour la navigation dans les répertoires et le chargement des pages sur de gros dépôts
- GitLab prévoit d’abandonner Gollum
- Le CMS basé sur Git (Decap) atteint la limite de 5 000 requêtes de l’API GitHub
- Les performances se dégradent au-delà d’environ 10 000 entrées, et les nouveaux utilisateurs avec un cache vide provoquent une explosion des requêtes
- Les outils GitOps (ArgoCD) rencontrent des problèmes de dépassement d’espace disque lors du clonage des dépôts
- Un seul commit invalide l’intégralité du cache, et les gros monorepos nécessitent un dimensionnement séparé
Pourquoi Git est structurellement mal adapté comme base de données
- Limites des répertoires : plus le nombre de fichiers augmente, plus cela ralentit
- CocoaPods devait gérer 16 000 répertoires, ce qui générait d’énormes objets d’arbre, problème résolu par un sharding fondé sur le hachage
- Problème de sensibilité à la casse : Git distingue les majuscules/minuscules, mais macOS et Windows non
- Azure DevOps a ajouté une fonction de blocage côté serveur pour éviter les conflits
- Limite de longueur des chemins : la limite de 260 caractères de Windows provoque des erreurs
git status
- Absence de fonctions de base de données :
- Pas de contraintes CHECK/UNIQUE, pas de verrouillage, pas d’index, pas de migrations
- Chaque gestionnaire de paquets doit construire son propre système de validation et d’indexation
Conclusion
- Git est excellent pour la collaboration sur le code source, mais il est mal adapté aux requêtes sur les métadonnées de paquets et à la gestion de registres à grande échelle
- La plupart des gestionnaires de paquets finissent par migrer vers des index basés sur HTTP ou des bases de données
- Les avantages de Git (historique des versions, workflow de PR) sont attractifs, mais il échoue comme substitut à une base de données
- Lors de la conception d’un nouveau gestionnaire de paquets, même si un index Git paraît séduisant, on atteint les mêmes limites que dans les cas de Cargo, Homebrew, CocoaPods, vcpkg et Go
Aucun commentaire pour le moment.