Skip to main content
Use this runbook when bundled PostgreSQL pods need more or less CPU or memory. This applies to PostgreSQL created by the metoro-onprem chart and managed by CloudNativePG. If PostgreSQL is externally managed, change resources through the team and tooling that operate that PostgreSQL service. The Metoro chart does not manage external PostgreSQL pod resources.

​
Check Usage First

Before changing resources, inspect sustained PostgreSQL CPU, memory, throttling, restart, and scheduling signals. Use Metoro’s hub dashboards where available, Kubernetes pod metrics, and recent events. Resize based on sustained pressure or PostgreSQL symptoms, not a single short spike. Useful signals include:
  • PostgreSQL pods using most of their CPU or memory for a sustained period.
  • Non-zero CPU throttling.
  • OOM restarts or memory-limit errors.
  • PostgreSQL pods stuck Pending because requests do not fit available nodes.
  • Apiserver metadata operations becoming slow or failing.
  • Temporal persistence errors or workflow progress issues.

​
What To Change

The postgres.bundled.cluster.resources Helm values control PostgreSQL CPU and memory requests and limits. The chart renders these values into spec.resources on the CloudNativePG Cluster named metoro-postgresql. Change the values in metoro-hub-values.yaml: 
postgres:
  bundled:
    cluster:
      resources:
        requests:
          cpu: "2"
          memory: 4Gi
        limits:
          cpu: "2"
          memory: 4Gi
CPU requests affect Kubernetes scheduling and reserved capacity. CPU limits cap runtime CPU usage; a CPU limit that is too low can cause throttling. Memory requests affect Kubernetes scheduling. Memory limits cap PostgreSQL memory; a memory limit that is too low can cause OOM restarts, failed queries, or unstable application behavior. For PostgreSQL workloads, CloudNativePG recommends Guaranteed QoS when practical. To get Guaranteed QoS, set CPU and memory requests equal to their limits. Changing CPU or memory does not resize PVCs. To increase PostgreSQL PVC capacity, see Upscale PVC. Changing CPU or memory does not add PostgreSQL instances. To change instance count, see Scale Instances.

​
Apply The Change

Apply the updated values with the same Helm release and chart version used for the hub: 
helm upgrade --install metoro oci://quay.io/metoro/charts/metoro-onprem \
  --namespace metoro-hub \
  --version 10.0.1 \
  --values metoro-hub-values.yaml

​
What Happens

After the Helm upgrade, the CloudNativePG Cluster named metoro-postgresql updates its spec.resources. CloudNativePG reconciles the updated cluster with a rolling update. PostgreSQL standby instances are updated first, one pod at a time. The primary is updated last. The chart uses primaryUpdateMethod: switchover and primaryUpdateStrategy: unsupervised, so CloudNativePG can promote an updated standby before replacing the old primary. Expect a rolling, switchover-aware process rather than all PostgreSQL pods restarting at once. Apiserver and Temporal may briefly observe PostgreSQL readiness changes and should recover as PostgreSQL endpoints settle. If pods become pending after increasing requests, check node capacity, node selectors, taints, topology constraints, and scheduler events. The requested pod shape must fit on available Kubernetes nodes.

​
Verify The Rollout

Check that the CloudNativePG cluster exists and is being reconciled: 
kubectl -n metoro-hub get cluster.postgresql.cnpg.io metoro-postgresql
Confirm the desired resources match the Helm values: 
kubectl -n metoro-hub get cluster.postgresql.cnpg.io metoro-postgresql \
  -o jsonpath='{.spec.resources}{"\n"}'
Watch PostgreSQL pods and roles while CloudNativePG reconciles: 
kubectl -n metoro-hub get pods -l cnpg.io/cluster=metoro-postgresql \
  -L cnpg.io/instanceRole -w
Check recent events if pods are pending or slow to restart: 
kubectl -n metoro-hub get events --sort-by='.lastTimestamp'
After the rollout, return to Metoro and Kubernetes metrics and verify that the original signal improved. If CPU, memory, or throttling does not improve, the bottleneck may be disk IO, PostgreSQL query shape, connection volume, Temporal load, or node capacity rather than pod resource sizing. Do not manually edit the CloudNativePG Cluster for normal resource changes. Keep metoro-hub-values.yaml as the source of truth and let Helm and CloudNativePG reconcile the change.