GitHub's new Git storage architecture
github.blog
github.blog
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.
It might be more of a send up to Firewatch these days: https://www.firewatchgame.com/
But I'm still waiting on someone to revive 2008's darling, resizing parallaxing: https://web.archive.org/web/20080302013806/https://www.think...
There're really security issues, and a black box creates black boxes.
I have no idea why I like this comment, but I do.
Hope it helps improve reliability, it was getting hard to defend GitHub with all the recent outages.
things such as shallow clone by default, applying lazy evaluations on repo with large commit volume (e.g. partial remote-related operations at branch level until it is switched to), etc.
if reading these overloaded graphs is the problem, most readers (nowadays through automated consumption) only care about the current snapshot of a project's code. that too in probably the main branch.
github can probably make the git maintainers implement this. feels like it is worth trying at least.
The problems of scale we're encountering are because bad developers are deploying bad quantities of bad agents against bad repos.
Vibe-coded repos occupy GB of space, utterly useless PRs are opened and closed due to conflicts with other useless PRs, and it turns out git is the problem!
Once they get it, agents will get it too! Eg. I'd switch over to bazaar/breezy with comparable performance to git — but mostly comparable adoption — right away.
Or alternatively someone is doing something very silly.
But there's a number of other big private repos with a high rate of merge on GitHub, and indeed it's currently a bit painful, e.g. the subroutine that check whether a PR can be merged tend to take ages. So my read is that they want to better support these big customers out of concern that they might leave too.
Every day, he sends hundreds of commits to his (most likely vibecoded) repositories of retro games recompilation.
Given its prominence in some of these other discussions from GitHub of a repo always on their performance radar now my gut instinct is that it could be the Windows monorepo.
Alternatively, something from IBM with 60 years of commit history.
Edit: https://assets.theregister.com/2026/04/04/azure_talent_exodu... The blog post that story is based on was also on HN.
Edit2: https://news.ycombinator.com/item?id=47616242 (1297 points)
What do those uptime numbers tell? For 95% of the problems I had the status page has no information.
Azure was the cloud that had all global auth rely on a single DC in Texas (we learned when cooling failed there), and didn't have availability zones in most regions until not that long ago. They've also had a number of trivial cross tenant exploits. No, two us-east-1 outages that had minal global impact isn't comparable, we're talking about all auth for all of Azure using a single DC, not a region of 5 DCs having the control plane for global AWS services.
Neither security nor reliability are a priority. It's by far the worst big cloud provider, and it's not even remotely close.
Sure, it's nice that you can technically handle it, but to me it sounds like at that point something has gone absolutely horribly wrong in the way you set up your agents. Last time I checked, GitHub was intended as a platform to upstream finished work items, not a realtime cross-agent chat channel.
Handling thousands of git pushes per second implies thousands of issues, thousands of PRs, tens of thousands of comments, thousands of Actions runs, and dozens of releases. How's that part of their infra going to scale?
How about introducing rate limits instead, nudging people to not have agents push every individual single-line changes to GH, but instead have them collaborate as a local cluster and only upstreaming PR-sized chunks of finished work?
If you still need thousands of pushes per second you'd be looking at millions of lines of code, and at that point you're looking at an insane monorepo which is growing at a rate of terabytes per day, and which basically instantly becomes unusable due to being impossible to clone or check out.
It's not unreasonable to imagine thousands of commits per second to the kernel, especially if you consider that bots might be watching LKML and applying patches to various forks.
> Handling thousands of git pushes per second implies thousands of issues, thousands of PRs, tens of thousands of comments, thousands of Actions runs, and dozens of releases. How's that part of their infra going to scale?
For each issue my agent might raise 5 independent PRs as experiments.
Further, the more changes there are, the more important it is that they don't conflict, which means smaller changes, which means even more changes.
Bots interleaving typos, single line whitespace fixes, single dependency bumps, etc.
I'm starting to think AI isn't a productivity machine, but rather a machine for hypnotising people into the false belief of productivity.
The only conceivable scenario that I can imagine leading to this volume of writes is a push-based GitOps repository for a huge cluster holding a large volume of apps, each one with many services. Each commit in one if these services triggers a commit to the gitops repo to update the reference to the new container image, which in turns triggers a deployment update.
There is no software project on earth that justifies a rate of changes in magnitudes of dozen of commits per second. This is a symptom of a huge problem, not a sign of times. Even in monorepo mania this sort of thing is inconceivable.
But that's also what you get with vibecoding: lots of output from people who do not have a clue about what they are doing.
Companies pay GitHub for enterprise repositories. It’s not completely wild that a 2026 large scale company would have the same scale as 2016 Google…
Besides, you can push amends to your branch, or describe/review/squash your changes at PR merge time anyway, so what's the harm of a zillion pushes? Other than "GitHub engineers have to invent a novel database", that is. But that's probably enrichment for them.
For example, you can clone a repo from GitHub into your workstation,and then clone that repo into multiple folders in your workstation where you unleash agents to implement changes. The you pull those changes to your local repo or even directly to GitHub or GitLab or whatever. That's pretty decentralized.
Now, compare this to the god awful mess that was subversion.
GitHub is still a single source of truth in that scenario.
BTW, it's unclear what exactly you think is wrong with SVN. Works great when used properly (like any tool, you know).
Imagine the token costs!
My company with about 60 devs in the backend dev slack channel probably produces less commits per year together.
Does my company already belong to the permanent AI underclass?
I commit that amount per year (alone, no AI, dev is not my main work)
Pretty much everything in Git can be abstracted away as “immutable blobs that can be conveniently content-indexed” and an “event log”. The former is inherently parallel and the latter can be partitioned by repo.
The volume of metadata events that require synchronisation or similar transactional semantics seems low enough per partition to allow off-the-shelf systems to handle without a custom storage solution…
Multiple terabytes is no problem out of the box. You get exclusive locking of files. You can easily take partial checkouts of the monolith. Centralization is a feature in this particular context. Git works great if the need for coordination is moderate. If you've got thousands of automated developers with their hands in the cookie jar, exclusive locks start to look really compelling. Perforce sucks with a highly distributed team, but in the case of an AI agent swarm we presumably have the ability to instantly nuke an agent's checkout if needed. I don't have to contact the agent and wait for them to get out of bed.
Holding on for dear life and failing is more like it.