Managed PostgreSQL (Planned)
Purpose: For platform engineers, explains the planned scope for Managed PostgreSQL including operator selection and backup/restore model.
Status
openCenter Managed PostgreSQL is planned for preview in Q2 and GA in Q3, following the sequencing defined in ADR-004. Managed Kafka ships first (Q1 GA) because its support boundary is easier to define and its blueprint fit is stronger. PostgreSQL follows once the stateful service framework and operational procedures are proven with Kafka.
This document describes the intended scope. Details may change during design partner validation.
Why PostgreSQL
PostgreSQL is the most requested transactional database across openCenter's customer base. Application teams need a managed relational database for:
- Application backends (CRUD workloads, session state, configuration storage)
- Internal platform services that require SQL (Keycloak, Harbor, custom tooling)
- Reporting and analytics queries against operational data
- Microservice data stores where each service owns its schema
PostgreSQL is a strong second service because demand is high and the operator ecosystem is mature. The risk is that buyer expectations tend toward "DBA as a service" — customers may expect the platform team to own query performance, schema design, and migration support. The support boundary must be explicit from day one.
Planned Blueprint Scope
Included in v1
| Component | Notes |
|---|---|
| PostgreSQL operator | Operator selection in progress (candidates: CloudNativePG, Zalando postgres-operator) |
| HA cluster topology | Primary + streaming replicas; automatic failover |
| TLS encryption | cert-manager integrated, mandatory in transit |
| Authentication | Password-based (SCRAM-SHA-256) and certificate-based |
| Automated backups | Scheduled base backups + continuous WAL archiving |
| Point-in-time recovery | Restore to any point within the retention window |
| Monitoring | Prometheus metrics via postgres_exporter, Grafana dashboards |
| GitOps lifecycle | Declarative CRDs managed through FluxCD |
| Air-gap packaging | Images mirrored through Harbor |
Not included in v1
| Feature | Reason |
|---|---|
| Logical replication | Adds complexity; defer to add-on |
| Connection pooling (PgBouncer) | May be included if operator supports it natively; otherwise add-on |
| Custom extensions | Support matrix too broad; only default extensions |
| Multi-master / active-active | Not viable for v1 support model |
| Sharding | Out of scope for blueprint model |
| DBA services (query tuning, schema review) | Professional services only |
Operator Selection
Two operators are under evaluation:
| Operator | Strengths | Concerns |
|---|---|---|
| CloudNativePG | Active community, clean CRD design, built-in backup to object storage, Kubernetes-native | Younger project; fewer production references at scale |
| Zalando postgres-operator | Battle-tested at Zalando scale, Patroni-based HA, connection pooling built in | More complex CRD surface, tighter coupling to Patroni internals |
Selection criteria (weighted by openCenter priorities):
- CRD stability and upgrade path
- Backup/restore reliability and automation
- Air-gap compatibility (no external cloud dependencies)
- Observability integration (Prometheus metrics, log format)
- Community health and release cadence
- Fit with GitOps declarative management
The operator decision will be finalized during Q2 design partner work.
Backup and Restore Model
Backup is a core requirement — not an add-on. The v1 blueprint will include:
- Scheduled base backups — full cluster backup on a configurable schedule (default: daily)
- Continuous WAL archiving — write-ahead logs shipped to a backup target for point-in-time recovery
- Backup target — object storage (MinIO in air-gap, S3-compatible in connected environments) or persistent volume
- Retention — configurable retention window (default: 7 days of PITR capability)
- Restore procedure — documented runbook for restoring to a new cluster from backup
Restore testing is a shared responsibility: openCenter validates the platform restore procedure works; customers validate that their application-level recovery (data integrity, schema state) meets their requirements.
Shared Responsibility
The same model as Managed Kafka applies:
- openCenter owns: PostgreSQL deployment, operator lifecycle, HA failover, backup execution, monitoring, patching, certificate rotation
- Customer owns: schema design, query performance, data modeling, application connection management, data classification, retention business decisions
- Shared: capacity planning, DR objectives, restore validation, upgrade scheduling
Namespace and Naming
Following the naming standards:
| Item | Value |
|---|---|
| Product name | openCenter Managed PostgreSQL |
| Blueprint name | managed-postgresql-v1 |
| Namespace | data-postgresql |
| CRD names | Operator-specific (TBD) |
Dependencies
Managed PostgreSQL will use the same platform services as Managed Kafka:
- cert-manager for TLS certificates
- Prometheus + Grafana for monitoring (via postgres_exporter)
- Loki for log aggregation
- Harbor for image mirroring
- Kyverno for pod security enforcement
- FluxCD for GitOps reconciliation
- SOPS for secret encryption in Git
Timeline
| Milestone | Target | Gate |
|---|---|---|
| Operator selection finalized | Q2 start | Evaluation complete, CRD stability confirmed |
| Design partner deployment | Q2 | 1 customer running non-prod PostgreSQL |
| Backup/restore runbook validated | Q2 end | Successful restore drill documented |
| GA release | Q3 | Runbooks, SLOs, alert set, and support boundary documented |
Further Reading
- Portfolio Strategy — why PostgreSQL is second
- Kafka Overview — the first data service (reference for patterns)
- Naming Standards — product and resource naming