analytically

  At 500 stations:
  - H3: 218µs, 4.7KB, 109 allocs
  - Fallback: 166µs, 1KB, 37 allocs
  - Fallback is 31% faster

  At 1000 stations:
  - H3: 352µs, 4.7KB, 109 allocs
  - Fallback: 312µs, 1KB, 37 allocs
  - Fallback is 13% faster

  At 2000 stations:
  - H3: 664µs, 4.7KB, 109 allocs
  - Fallback: 613µs, 1KB, 37 allocs
  - Fallback is 8% faster

  At 4500 stations (real-world scale):
  - H3: 1.40ms, 4.7KB, 109 allocs
  - Fallback: 1.34ms, 1KB, 37 allocs
  - Fallback is 4% faster

  Conclusion: The gap narrows as station count increases. At 4500 stations they're nearly equivalent. H3 has fixed overhead (~4.7KB/109 allocs for k=2 ring), while fallback scales linearly. The crossover point where H3 wins is likely
  around 10-20K entries.

Got tired of helping enterprises run Concourse themselves, so we productized it. We've deployed and maintained Concourse for Starbucks, Accenture, Sky UK, and others over the years—CentralCI packages that operational knowledge into a SaaS.

Why Concourse over GitHub Actions?

* fly execute lets you test pipelines locally before pushing. No more "commit and pray" * fly intercept drops you into a running container to debug failures * Resource-based triggers can monitor anything—not just git pushes * Full pipeline visualization from dev to prod in one view * Workers you actually control (no arbitrary cache limits or runner queues)

What we handle:

* Dedicated Concourse instances on high-spec hardware (Ice Lake Xeon, DDR5, NVMe) * Worker scaling without the Kubernetes complexity * SOC compliance, auditing, AWS PrivateLink for enterprise * 24/7 support from people who've been running Concourse in production for years

The pitch is simple: Concourse is the right tool for complex CI/CD, but running it is a pain. We make it not a pain.

https://github.com/centralci/go-benchmarks/tree/b647c45272c7...