metoro-onprem chart and managed by CloudNativePG. If PostgreSQL is externally managed, size it with the team that owns that service.
What PostgreSQL Stores
PostgreSQL is durable control-plane state for the hub. It stores users, roles, organizations, environments, dashboards, alerts, integrations, and Temporal workflow state. Because this data is critical, operators should size PostgreSQL conservatively, keep persistent volumes retained, and make sure backups are configured before production use.Starting Point
The default bundled PostgreSQL shape is:| Setting | Default | Meaning |
|---|---|---|
| Instances | 3 | One primary plus standby instances managed by CloudNativePG. |
| PGDATA PVC | 20Gi per instance | Live PostgreSQL data volume for each instance. |
| CPU request | 200m per instance | Scheduling request for each PostgreSQL pod. |
| Memory request | 1Gi per instance | Scheduling request for each PostgreSQL pod. |
| CPU limit | 1000m per instance | Runtime CPU cap for each PostgreSQL pod. |
| Memory limit | 2Gi per instance | Runtime memory cap for each PostgreSQL pod. |
CPU And Memory
PostgreSQL resource needs are usually driven by metadata traffic, Temporal persistence, active workflows, query shape, and connection volume. Watch for sustained CPU pressure, CPU throttling, high memory usage, OOM restarts, slow API metadata operations, and Temporal persistence errors. CloudNativePG recommends using Kubernetes resource requests and limits for PostgreSQL pods. When practical, set CPU and memory requests equal to limits so PostgreSQL pods receive theGuaranteed QoS class.
To change bundled PostgreSQL CPU or memory resources after installation, see Change PostgreSQL Resource Usage Whilst Running.
Instances
Metoro normally runs bundled PostgreSQL with3 instances in production. CloudNativePG runs one primary and the remaining instances as standbys.
Three instances provide high availability and allow CloudNativePG to perform switchovers during maintenance and rolling updates. A single-instance deployment is supported by PostgreSQL, but it has no standby to promote and maintenance can become a PostgreSQL outage.
To change bundled PostgreSQL instance count after installation, see Scale Instances.
Storage
CloudNativePG creates and manages PVCs directly for PostgreSQL. Each PostgreSQL instance gets one PGDATA PVC. If separate WAL storage is enabled, each instance also gets a WAL PVC. Size live storage per instance first, then multiply by the instance count for total raw PVC capacity. For example,20Gi of PGDATA with 3 instances needs about 60Gi of raw PGDATA PVC capacity before storage-system replication, snapshots, and backup overhead.
Backups and object storage are separate from live PVC sizing. Plan backup storage from retention policy, backup frequency, database size, WAL volume, compression, and the storage system’s own replication or versioning overhead.
Use retained, resizable storage that is appropriate for database workloads. For Metoro on-premises, prefer network-attached storage unless the platform team has explicitly accepted the scheduling and maintenance constraints of local storage. CloudNativePG recommends benchmarking storage for database workloads before production use.
To increase bundled PostgreSQL PVC capacity after installation, see Upscale PVC.