Re:GitHub's new Git storage architecture
by pksunkara on Friday November 06, 2026 @08:30PM
(#50400747)
Since they wouldn't need to actually have the inactive repositories on disk anymore, I reckon it should solve the horizontal scale issue too by reducing the compute/disk capacity that needs to be maintained.
Disclaimer: I am building a code forge myself at https://juju.bi, so I am definitely not biased.
Re:GitHub's new Git storage architecture
by rockwotj on Friday November 06, 2026 @08:44PM
(#50400822)
personally I see more issues with actions over pushing
What? 7.2k CI runs per second is a piece of cake! ;-)
Re:GitHub's new Git storage architecture
by aniceperson on Sunday November 08, 2026 @06:32PM
(#50418872)
the ci problem I think is fundamentally easier, since each is its own instance, you just need an orcestrator to coordinate, that can also be one per a group of repositories (there are no cross-repo triggers anyway). The actions issues we keep facing seem to be at the agregation/collector side of things, similar to general api issues, not a fundamental kubernetes scaling issue.
I'd have thought so from the headline + initial content but then they say that the horizontal scale techniques are basically carrying over from the existing architecture (where it seems the problem is?) and this is mostly to help with what they call "vertical scale" (intra-repo scalability). They also admit right after that the most active repos today will receive short bursts of at most dozens of writes.
So this seems like really useful planning for a near future that likely helps prevent more issues but isn't really meant to help current issues. Am I reading this right?
Of course improvements like this are always useful either way. Not dunking here at all.