Skip to main content

Managed PostgreSQL (Planned)

Purpose: For platform engineers, explains the planned Managed PostgreSQL service — operator selection, capabilities, backup model, and timeline.

Status

Preview — Q2 2026 start, targeting Q3 2026 GA.

Operator selection between CloudNativePG and Zalando postgres-operator is in progress. Both candidates meet the selection criteria; final decision pending production validation.

Why PostgreSQL

  • Most requested database from customers
  • Required before CDC (Debezium captures from PostgreSQL)
  • Mature operator ecosystem with two strong candidates
  • Horizontal dependency for many application architectures

Included in v1

CapabilityDescription
Cluster provisioningSingle-primary with streaming replicas
High availabilityAutomated failover (operator-managed)
BackupScheduled base backup + continuous WAL archiving
Point-in-time recoveryRestore to any WAL position within retention window
Rolling upgradesMinor and major version upgrades with managed switchover
Connection poolingPgBouncer sidecar or dedicated pool
MonitoringPrometheus exporter + Grafana dashboards + alerting rules
TLScert-manager issued certificates for client and replication
AuthenticationSCRAM-SHA-256, certificate-based
GitOps lifecycleCRDs in Git, FluxCD reconciliation
Air-gap supportAll images mirrorable

Excluded from v1

CapabilityRationale
Logical replicationComplexity; defer to CDC service (Q1 2027)
Multi-regionRequires cross-cluster networking; future scope
Read replicas with load balancingDeferred pending demand signal
Custom extensionsSecurity review required per extension; curated list only
Managed PgBouncer (standalone)Connection pooling via sidecar is sufficient for v1

Operator Comparison

CriteriaCloudNativePGZalando postgres-operator
MaturityGA, CNCF SandboxGA, production at Zalando
BackupBarman-based, object storageLogical + physical, S3/GCS/Azure
FailoverAutomated, raft-based leader electionAutomated via Patroni
UpgradesIn-place minor, managed majorIn-place minor, managed major
CRD APICluster (single CRD)postgresql + OperatorConfiguration
MonitoringBuilt-in Prometheus exporterSidecar exporter
CommunityActive, regular releasesActive, large user base
Air-gapStandard images, no external callsStandard images, no external calls

Selection criteria: day-2 operations maturity, backup/PITR reliability, upgrade safety, CRD API stability, community activity.

Backup and Restore Model

OperationMechanismRPO
Base backupScheduled (daily default) to object storage24h (configurable)
WAL archivingContinuous streaming to object storageSeconds (near-zero)
Point-in-time recoveryRestore base + replay WAL to target timestampSeconds
Cluster cloneCreate new cluster from backupN/A

Object storage backends: S3-compatible (MinIO in air-gap), or cloud provider object store.

Support Boundary

openCenter ResponsibilityCustomer Responsibility
Operator deployment and upgradesDatabase schema design
Cluster provisioning and HAApplication queries and indexes
Backup scheduling and retentionData content and quality
Monitoring and alertingApplication connection management
TLS and credential rotationPerformance tuning (query-level)
Failover and recoveryCapacity planning input

Naming

  • Product: openCenter Managed PostgreSQL
  • Namespace: data-postgres
  • Blueprint: managed-postgres-v1
  • Helm release: per operator choice

See Naming Standards for full conventions.

Dependencies

DependencyPurpose
cert-managerTLS certificates
kube-prometheus-stackMetrics and alerting
LokiLog aggregation
KyvernoPolicy enforcement
FluxCDGitOps reconciliation
Object storageBackup target (S3-compatible)
VeleroOperator state backup

Timeline

MilestoneTarget
Operator selection finalizedQ2 2026
Preview (backup/restore validated)Q2 2026
GA (full day-2 operations)Q3 2026

Further Reading