> ## Documentation Index
> Fetch the complete documentation index at: https://metoro.io/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Change PostgreSQL Resource Usage Whilst Running

> Change bundled PostgreSQL CPU and memory resources for Metoro on-premises deployments

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`:

```yaml theme={null}
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](/docs/on-premises/10.x/operations/postgresql/upscale-pvc).

Changing CPU or memory does not add PostgreSQL instances. To change instance count, see [Scale Instances](/docs/on-premises/10.x/operations/postgresql/scale-instances).

## Apply The Change

Apply the updated values with the same Helm release and chart version used for the hub:

```bash theme={null}
helm upgrade --install metoro oci://quay.io/metoro/charts/metoro-onprem \
  --namespace metoro-hub \
  --version 10.4.0 \
  --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:

```bash theme={null}
kubectl -n metoro-hub get cluster.postgresql.cnpg.io metoro-postgresql
```

Confirm the desired resources match the Helm values:

```bash theme={null}
kubectl -n metoro-hub get cluster.postgresql.cnpg.io metoro-postgresql \
  -o jsonpath='{.spec.resources}{"\n"}'
```

Watch PostgreSQL pods and roles while CloudNativePG reconciles:

```bash theme={null}
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:

```bash theme={null}
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.