CYBERTEC PG Operator for PostgreSQL on Kubernetes

Running PostgreSQL in Kubernetes is easy to begin and hard to operate well. A StatefulSet can start a database, but production teams also need replication, failover, backups, upgrades, credentials, storage changes, and a safe way to repeat the same setup across environments.

The CYBERTEC PG Operator turns those tasks into a declarative Kubernetes workflow. Platform engineers and DBAs describe the required PostgreSQL cluster as code, then the operator works with Kubernetes and Patroni to keep the deployed cluster aligned with that definition.

For organizations standardizing applications on Kubernetes, this can reduce one-off database procedures and make PostgreSQL operations fit the same GitOps practices used for the rest of the platform.

What is the CYBERTEC PG Operator?

The CYBERTEC PG Operator, also called CPO, is a Kubernetes operator for creating and managing highly available PostgreSQL clusters. It uses custom resources as the configuration interface, Kubernetes as the orchestration layer, and Patroni for PostgreSQL high availability.

That model changes how teams manage the database lifecycle. Instead of asking an administrator to perform every change by hand, the desired state lives in version-controlled manifests. The operator can then coordinate provisioning, replication, updates, failover, backups, and related services.

CPO supports public cloud, on-premises, and hybrid Kubernetes environments. It is also compatible with OpenShift and is designed to work with CI/CD and GitOps tools such as Argo CD and Flux.

The main operational benefits

### Repeatable PostgreSQL provisioning

Custom resources give teams one declarative way to define clusters. The same reviewed manifest can move through development, testing, and production with environment-specific values kept under version control.

This improves consistency and auditability. A reviewer can see a requested storage, version, or configuration change before it reaches the cluster. Teams also gain a clear record of how the database platform changed over time.

### High availability with less manual coordination

CPO uses Patroni for leader election, streaming replication, and failover. Kubernetes provides scheduling and workload recovery, while pod anti-affinity can distribute database instances across nodes.

Together, these controls help the cluster recover from common pod or node failures without relying on a person to coordinate every step. High availability still depends on sound infrastructure, storage, networking, and testing, but the operator makes the PostgreSQL control loop repeatable.

### A better fit for GitOps and CI/CD

The operator is built around Kubernetes resources, so database provisioning can join an existing deployment pipeline. Teams can use pull requests, policy checks, and automated promotion instead of maintaining a separate ticket-driven process for every PostgreSQL cluster.

CPO also supports workflows where application teams do not receive direct Kubernetes API access. Platform teams can expose a controlled, reviewed path for requesting database resources while retaining cluster governance.

### More portable infrastructure choices

CPO runs on Kubernetes-compatible infrastructure across cloud and on-premises environments. That gives organizations a consistent operating model when they use more than one environment or want to avoid binding the database lifecycle to a single managed service.

Portability is not the same as zero migration effort. Storage classes, identity, networking, backup destinations, and observability still vary by platform. The benefit is that the PostgreSQL cluster definition and operational model remain familiar.

Features that matter in production

### Rolling changes and PostgreSQL upgrades

CPO supports rolling updates for cluster changes and minor version upgrades. It also provides in-place major upgrades across clusters. Combined with failover mechanisms, this can reduce service interruption compared with a fully manual upgrade sequence.

Upgrade automation does not remove the need for preparation. Teams should still test extensions, application compatibility, backup recovery, and rollback procedures before changing a production major version.

### Backup, restore, and point-in-time recovery

The operator integrates PostgreSQL backup and point-in-time recovery with pgBackRest or pg_basebackup. Backup targets can include persistent volumes, AWS, Google Cloud Storage, and Azure. Client-side backup encryption is also supported.

This gives teams a path to manage backup configuration alongside the cluster. The practical benefit is consistency: retention, destinations, credentials, and restore procedures can follow a standard platform pattern rather than being rebuilt for each database.

A scheduled backup is not proof of recoverability. Production teams should restore into an isolated environment, measure recovery time, and verify application data regularly.

### Connection pooling with pgBouncer

CPO can deploy pgBouncer for database connection pooling. This is useful for applications that create many short-lived connections or need a stable connection endpoint while PostgreSQL instances change roles.

Pooling can protect database resources, but it needs deliberate sizing and a pooling mode that matches application behavior. Transactions, prepared statements, and session-level settings should be tested before rollout.

### Storage growth without routine restarts

Live volume resize is supported when the underlying storage class allows it. The volume can grow without restarting the PostgreSQL pod in compatible environments.

That removes a common maintenance event, but capacity monitoring still matters. Automatic expansion should be paired with thresholds and alerts so teams understand why storage is growing before space becomes urgent.

### Credentials and TLS at the Kubernetes layer

CPO can manage users and credentials through Kubernetes and supports custom TLS certificates. These features help platform teams connect PostgreSQL access to their existing secret-management and certificate processes.

The operator also supports Transparent Data Encryption integration with CYBERTEC PostgreSQL Enterprise Edition. That option is relevant when an organization has encryption or compliance requirements that go beyond standard PostgreSQL capabilities.

### Standby and multisite clusters

The operator supports standby clusters and multisite clusters with automatic failover. These designs can improve resilience when a single Kubernetes cluster or site is not an acceptable failure boundary.

Cross-site PostgreSQL needs careful network, latency, recovery-point, and split-brain planning. The feature provides the automation layer, while the architecture must still match the organization's recovery objectives.

### PostgreSQL extensions and current versions

The official project lists support for PostgreSQL 13 through 18 in CPO 0.9.1. It also documents integrations for widely used extensions including PostGIS, pgAudit, TimescaleDB, pg_cron, credcheck, and set_user.

Extension compatibility can vary by PostgreSQL version and image. Confirm the exact extension build and upgrade path before selecting a production image.

Where CPO can reduce operational risk

The strongest use case is a team that already runs Kubernetes and wants PostgreSQL to follow the same controlled delivery model. CPO is especially relevant when the platform must provide:

Repeatable, self-service database provisioning through reviewed manifests
Highly available PostgreSQL without building a custom Patroni automation layer
Standard backup, restore, TLS, credential, and pooling patterns
A consistent operating model across cloud, on-premises, or hybrid clusters
GitOps integration for database lifecycle changes

An operator is not a substitute for PostgreSQL expertise. Query design, indexing, capacity planning, recovery testing, security reviews, and observability still require ownership. CPO automates repeatable control-plane work so specialists can spend more time on those database concerns.

A practical adoption path

Start with one non-critical workload and define measurable acceptance tests. Verify initial provisioning, planned switchover, unplanned failover, node loss, backup creation, point-in-time restore, credential rotation, certificate renewal, volume expansion, and both minor and major upgrades.

Next, connect the cluster definition to the organization's GitOps workflow. Add policy checks for storage, replica counts, backup configuration, allowed images, resource limits, and network access. Document which settings application teams may change and which remain under platform control.

Before production, run a recovery exercise that assumes a real failure. Restore the database into a clean environment, reconnect a test application, and compare the observed recovery time and data loss with the business target.

Build your PostgreSQL platform with Worlber

Worlber helps organizations assess, design, deploy, and operate PostgreSQL on Kubernetes with the CYBERTEC PG Operator. We align high availability, backup and recovery, GitOps, security, storage, and observability with your infrastructure and recovery requirements.

Talk to Worlber about your PostgreSQL platform