Everyone is doing Git on S3 wrong

7 points by typesanitizer

robalex

7,600+ concurrent pushes per second on a single repository at millisecond latency; more than an order of magnitude faster than existing solutions

I've found that lots of pushes (hundreds per hour for a dozen developers) usually means that there's a CI system that runs tests that aren't running locally. I usually fix that by helping developers get their tests running on their local systems. That tends to get them faster feedback than having commits wait in a CI/CD queue, so they prefer it.

If a project is really seeing thousands of pushes per second I suspect they are doing something quite wrong.

typesanitizer
(Not affiliated with the authors) I think it's a bit short-sighted to only think of that number literally. Some other ways of thinking about high throughput:
- If your load is far from the point of saturation, it's likely that tail latencies will have low variance.
- You're very efficient, leaving a fair bit of spare capacity for other operations (e.g. a VCS server will always see a mix of various request types, not just pushes, except for when the repo is being initially imported)
- robalex
  
  I think it's the comparison to existing systems that falls flat for me. They imply that existing S3-based Git repos can handle, perhaps, hundreds of pushes per second with tens or maybe hundreds of milliseconds of latency. Those are already fantastic numbers that far outpace the needs of even purely agentic workflows. There is already tons of spare capacity.
  
  It feels like trying to sell a car as having a top speed that is faster than the competition when the competition is already significantly faster than the speed limit. If the acceleration or handling is better, then market that. Otherwise it's a vanity metric.