What's this about?
The engineering post behind Origin — tracing 20 years of Git infrastructure and explaining why Cursor designed and operates its Git storage as if it were a database — reached HN with its own 281-point thread, landing in the same week as GitHub's outage postmortem.
What exactly is the scaling limit in Git hosting?
Git was designed for distribution: everyone has a full copy, and the server is a meeting point. Its storage reflects that — loose objects and packfiles, tuned for a single machine and modest concurrency. That's fine when writers are people. It stops being fine when a dozen agents commit continuously to one repository, because you need transactional guarantees, cross-region consistency and high concurrent write throughput — the properties databases were built for and filesystems weren't.
Why is this worth noticing?
- The timing turned a vendor post into an argument. GitHub's postmortem, in the same week, disclosed commit volume doubling in four months — which is the exact load Cursor is claiming to design for.
- It's a rare engineering rationale published alongside a competitive product, which makes it more useful than a launch post even for people who won't switch.
- It reframes hosting as a database problem, and if agent commit volume keeps climbing, that reframing is either prescient or self-serving depending on how the next year goes.