This RFE covers binary storage format for CRs which would allow us to increase density and scale of controllers by ~10x (based on memory of the original protobuf improvement).

Currently the number of CustomResources per type that can be created is limited by the memory and CPU usage incurred when listing all of a particular type and encoding it. While limits can be improved by using watch-from-beginning instead of list, the result is smearing (flatten the curve) as opposed to limiting the overall decoding/encoding cost (integral under the curve). The next level of improvement could come from encoding/decoding using a binary storage format similar to protobuf instead of using JSON. I don't know the most suitable format to use (part of this would have to include a survey of options), but there is appetite upstream to do this and doing so would improve the CPU, memory, and scale for every kube-apiserver, including those used for ACM or powering ROSA.