Portfolio Strategy

Purpose: For platform engineers and leadership, explains the data services portfolio strategy — what ships when, why in that order, and how the commercial model works.

Blueprint Model

Each data service follows the same pattern:

1. Versioned blueprint in openCenter-gitops-base (Helm + Kustomize + hardened values)
2. Operator-managed lifecycle (no manual kubectl; CRDs drive everything)
3. Shared platform dependencies (cert-manager, Keycloak, Prometheus, Kyverno, FluxCD)
4. Day-2 operations defined before GA (backup, restore, upgrade, scale, rotate credentials)
5. Air-gap compatible (all images mirrorable, no runtime internet dependency)

Timeline

Quarter	Milestone	Deliverable
Q1 2026	Kafka Limited Availability	Strimzi-backed Kafka clusters, topics, users, ACLs. First paying customers.
Q2 2026	PostgreSQL Preview	Operator selection finalized. Preview clusters with backup/restore.
Q3 2026	PostgreSQL GA	Production-ready managed PostgreSQL with PITR, failover, upgrades.
Q4 2026	Schema Registry	Schema versioning and compatibility enforcement as Kafka add-on.
Q1 2027	Change Data Capture	Debezium-based CDC for PostgreSQL-first patterns.

Sequencing Rationale

Kafka first because:

• Strimzi operator is mature (production-ready CRDs, active community)
• Streaming is a horizontal dependency for CDC and event-driven architectures
• Customers already run Kafka; managed service reduces operational burden

PostgreSQL second because:

• Most common database request
• Required before CDC (CDC captures from PostgreSQL)
• Operator ecosystem has two strong candidates (CloudNativePG, Zalando)

Schema Registry before CDC because:

• Schema enforcement prevents data quality issues before they propagate through CDC pipelines
• Smaller scope — add-on to existing Kafka infrastructure

What Is In Scope

Launch (committed roadmap)

• Apache Kafka (Strimzi operator)
• PostgreSQL (operator TBD — CloudNativePG or Zalando)
• Schema Registry (Kafka add-on)
• Change Data Capture (Debezium on KafkaConnect)

Deferred (evaluated, not on current roadmap)

• Redis/Valkey — caching use cases acknowledged, no operator selection started
• RabbitMQ — messaging use cases acknowledged, deferred pending Kafka adoption data
• MongoDB — not evaluated
• Elasticsearch/OpenSearch — observability stack covers log search needs

Excluded

• Serverless/consumption-based pricing models
• Multi-cloud managed services (AWS RDS, Azure CosmosDB wrappers)
• Data warehouse / OLAP engines
• ML feature stores

Selection Criteria

A data service enters the roadmap when it meets all of:

1. Operator maturity — stable CRD API, active maintenance, production deployments
2. Customer demand — multiple customer requests or clear horizontal dependency
3. Operational clarity — day-2 operations (backup, upgrade, scale) are well-defined
4. Air-gap viability — all images and charts mirrorable
5. Commercial clarity — attachable day-2 revenue model

Commercial Model

Tier	Includes	Target
Foundation	Platform foundation + GitOps automation	All customers
Enterprise	Foundation + enterprise overlays + managed services (Kafka, PostgreSQL)	Customers needing managed data services
Regulated	Enterprise + compliance controls (Finance, Healthcare, Telco blueprints)	Regulated industries

Responsibility Boundaries

Responsibility	openCenter	Customer
Operator deployment and upgrades	✅
Cluster provisioning and scaling	✅
Backup scheduling and retention	✅
Monitoring and alerting	✅
Topic/database/user creation		✅ (via CRDs in Git)
Application data and logic		✅
Schema design		✅
Performance tuning (application-level)		✅

Further Reading

• Data Services Overview — family overview and principles
• Streaming Blueprint — Kafka details
• Kafka Architecture — technical architecture
• PostgreSQL (Planned) — operator comparison and timeline
• Naming Standards — naming conventions for data services