How would you predict when a GitOps hub becomes the bottleneck?
I wrote an honest reflection on trying to predict the scaling limits of GitOps fleet management with a Hub-and-Spoke architecture. Warning: it turned into a long blog post, around 45 minutes read time, based on 3–4+ months of intense learnings, 31 iterations, scale tests, wrong assumptions, long nights, weekend work, and support from the community and cloud providers.
TL;DR: We tested GitOps fleet management with Argo CD, vCluster, kubara, and Sveltos. In our setup, Argo CD’s application controller started hitting OOM kills around 15k–20k cached objects per hub. Hydrated manifests helped, tuning helped only partially, and Sveltos handled addon-style rollout patterns at a fraction of the memory: ~2 GB vs. ~21 GB for Argo CD. The main lesson: at very large scale, architecture matters more than tuning.
Not a benchmark claim, not “tool X beats tool Y”. Just sharing what we saw and learned, and why combining GitOps engines can be a real multiplier for what you can achieve with Open Source.