Please, answer some short questions which should help us to understand your problem / question better?

The logical backup cronjobs defines resource requests and limits from the cluster their are linked to which can be huge with big postgres deployments. This is inappropriate as the resource consumption of the logical backup pods are quite low and stable, and not related to the resource defined for the postgres cluster.

E.g. : If my cluster is defined with a 20 CPU and 200Gi RAM resource request, the logical backup job will define the same requests where in practice the pod itself consumes barely 1CPU (for compression mainly) and less than 1Gi of RAM.

• Which image of the operator are you using? registry.opensource.zalan.do/acid/postgres-operator:v1.8.0
• Where do you run it - cloud or metal? Kubernetes or OpenShift? [on premise virtualisation / Xen K8S]
• Are you running Postgres Operator in production? yes
• Type of issue? Bug report

A proposed solution would be to have sane defaults for resource requests and limits for the logical backup jobs, and optionnally be able to define these in the cluster CR directly (as well as other useful options like the retry backoff limits and job history limits)