El uso de almacenamiento de objetos como S3 para gestionar repositorios Git presenta limitaciones técnicas significativas debido a la naturaleza de Git como base de datos de grafos, no solo como almacenamiento de contenido. Aunque la infraestructura de Cursor/SpaceX, denominada Continuity, ha mejorado la durabilidad y la escalabilidad de las lecturas mediante un registro de escritura previa (WAL), sigue dependiendo de un único nodo para las escrituras masivas, lo que genera cuellos de botella en el rendimiento de pushes. El artículo explica que tratar Git como un simple sistema de almacenamiento de contenido ignora la necesidad de mantener la localidad de datos para seguir las cadenas de deltas y las referencias. Para lograr una escalabilidad real, la arquitectura debe mantener los objetos relacionados en proximidad física o lógica, evitando que cada operación de escritura requiera un viaje de red de 30 a 40 milisegundos. Esta distinción es crucial para soportar cargas de trabajo de agentes de IA a gran escala, donde cientos de clientes pueden empujar a un repositorio monorepo simultáneamente. La solución requiere mantener la coherencia de los datos en el almacenamiento de objetos mientras se optimiza el acceso local para las lecturas, superando las limitaciones de los sistemas que dependen exclusivamente de discos en disco duro.
