Database Operators

CloudNativePG, Redis Operator, CrunchyData — operators vs managed services.

8 min readDatabases for SREBuild

What Are Kubernetes Operators?

A Kubernetes operator extends the API with Custom Resource Definitions (CRDs) and controllers that automate complex stateful operations. For databases, operators handle provisioning, replication, failover, backup, and upgrades — tasks that would otherwise require manual intervention or custom scripts.

How operators work


# Operator pattern:
 # 1. CRD defines the desired state
apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: postgres-cluster
spec:
  instances: 3
  postgresql:
    parameters:
      max_connections: "200"
  storage:
    size: 100Gi

 # 2. Controller watches the CRD and reconciles reality
 #    - Creates StatefulSet, Services, ConfigMaps
 #    - Sets up replication between instances
 #    - Monitors health and handles failover
 #    - Manages backups on schedule

 # 3. Status reflects current state
 # kubectl get cluster postgres-cluster
 # NAME                STATUS    INSTANCES   READY   AGE
 # postgres-cluster    Cluster   3           3       5d

operators work on the reconciliation loop: you declare what you want (3 instances, 200 max connections), and the operator makes it happen -- and keeps it happening even if pods crash or nodes fail.

CloudNativePG

CloudNativePG cluster


apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: postgres
spec:
  description: "Production PostgreSQL cluster"
  imageName: ghcr.io/cloudnative-pg/postgresql:16.3
  instances: 3

  postgresql:
    parameters:
      shared_buffers: "256MB"
      work_mem: "16MB"
      max_connections: "200"
    pg_hba:
      - host all all 10.0.0.0/8 scram-sha-256

  storage:
    size: 200Gi
    storageClass: fast-ssd

  backup:
    barmanObjectStore:
      destinationPath: "s3://backups/postgres/"
      s3Credentials:
        accessKeyId:
          name: backup-secret
          key: ACCESS_KEY_ID
      secretAccessKey:
        name: backup-secret
          key: ACCESS_SECRET_KEY
    retentionPolicy: "30d"

  resources:
    requests:
      memory: "1Gi"
      cpu: "500m"
    limits:
      memory: "4Gi"
      cpu: "2"

  monitoring:
    enablePodMonitor: true

CloudNativePG is the most mature PostgreSQL operator. It handles replication (synchronous or asynchronous), automated failover, backups to S3, and rolling upgrades. It replaces the need for Patroni in Kubernetes.

CNPG handles WAL archiving automatically

CloudNativePG automatically configures WAL archiving to S3. You do not need to set up WAL-E, pgBackRest, or custom archive commands. Backups are managed declaratively through the CRD.

Redis Operator

Redis Enterprise operator


apiVersion: app.redislabs.com/v1
kind: RedisEnterpriseCluster
metadata:
  name: redis-cluster
spec:
  diskSize: 200Gi
  servicesListenerPort: 443
  username: admin@example.com
  redisEnterpriseNodeResources:
    limits:
      cpu: 4
      memory: 16Gi
    requests:
      cpu: 4
      memory: 16Gi

 # Or using Spotahome Redis Operator (open source)
apiVersion: databases.spotahome.com/v1
kind: RedisFailover
metadata:
  name: redis-failover
spec:
  sentinel:
    replicas: 3
  redis:
    replicas: 3
    resources:
      requests:
        cpu: 100m
        memory: 128Mi
      limits:
        cpu: 500m
        memory: 256Mi

Redis Enterprise operator provides clustering, replication, and Sentinel-based failover. The Spotahome operator is open-source and simpler — suitable for smaller deployments. Choose based on your scale and support requirements.

CrunchyData PGO

CrunchyData PostgresOperator


apiVersion: postgres-operator.crunchydata.com/v1beta1
kind: PostgresCluster
metadata:
  name: hippo
spec:
  postgresVersion: 16
  instances:
    - name: instance1
      replicas: 3
      resources:
        requests:
          cpu: 1000m
          memory: 1Gi
  backups:
    pgbackrest:
      repos:
        - name: repo1
          s3:
            bucket: postgres-backups
            region: us-east-1
            endpoint: s3.amazonaws.com
  proxy:
    pgBouncer:
      replicas: 3
      poolMode: transaction

CrunchyData PGO includes pgBouncer integration, pgBackRest for backups, and monitoring with Prometheus. It is a comprehensive operator that handles the full PostgreSQL lifecycle.

Operator Limitations

Operators add a layer of abstraction — debugging requires understanding both the operator and the database
Custom resources may have breaking changes between operator versions
Operator upgrades can require database restarts — plan maintenance windows
Not all database features are exposed through the CRD
Operator bugs can affect all managed instances
Community operators may lack production support

Managed Services vs Operators

Aspect	Managed Service	Operator
Operational burden	Lowest	Medium
Cost	Higher (premium)	Lower (self-managed)
Control	Limited	Full
Upgrades	Managed by provider	You control timing
Failover	Automatic	Automatic (with operator)
Backup	Built-in	Configured by you
Vendor lock-in	High	None (portable)

When to choose operators over managed

Choose managed services (RDS, ElastiCache, Atlas) when: you want minimal operational burden, your team is small, or compliance requires vendor support. Choose operators when: you need full control, have Kubernetes expertise, want to avoid vendor lock-in, or need custom configurations not available in managed services.

Mark this lesson complete to store local progress and unlock a cleaner resume path the next time you visit.

Stage 3 · Build

Databases in Kubernetes