Book a call ↗

Illustrative managed database environment with storage hardware and a database operations console

Project 06 / Sovereign-cloud databases

Database
as a service.

For a German cloud provider.

← All our work

The project

Where cloud infrastructure
meets the data layer.

Client
A German cloud provider
Our work
Database as a service
Environment
Sovereign cloud: the provider’s German data centres
Technology
CloudNativePG · PostgreSQL · Kubernetes
Across the stack
Infrastructure · Data

The service model

A service layer
for application data.

Database as a service gives applications access to databases through a managed platform.

Database resourcesStorage and compute
Database serviceOperators · Backups
ApplicationsThe provider’s customers
Conceptual service model

Engineering spotlight / PostgreSQL on Kubernetes

Managed databases.
Run by operators.

The database service a cloud provider offers its own customers: self-service PostgreSQL with high availability, automated backups and point-in-time recovery, run on Kubernetes by CloudNativePG.

1,200+

PostgreSQL clusters

Created by the provider’s customers through self-service.

<3min

To a new database

From a request in the console to a highly available cluster.

<30s

Automatic failover

A standby is promoted and the endpoint follows it, with no manual step.

14days

Point-in-time recovery

To any second in the window, from continuous WAL archiving.

Weekly

Restore tests

Backups are restored and verified on a schedule, not assumed to work.

EU

Data residency

Every database, backup and replica stays in the provider’s German data centres.

Client details are anonymised.

The challenge

Customers’ data.
The provider’s name on it.

A database service has to be easy for customers to use and safe for the provider to run at scale.

01 / Self-service

Databases on request.

Customers create, resize and remove databases without a ticket.

02 / Durability

Recovery that works.

Backups must be automatic, and restores must be tested.

03 / Isolation

Tenants kept apart.

Each customer’s data, network and resources are separated.

The operating stack

Every layer,
working together.

Each database is declared once and kept in shape by an operator. Observability and security run across the platform.

Customer access

Self-service API and console · Plans and sizes

Service control

Provisioning API · Tenant catalogue · Metering

Database operators

CloudNativePG · Streaming replication · Automated failover

Backup and recovery

Continuous WAL archiving · Base backups · S3-compatible storage

Kubernetes platform

Namespace per tenant · Network policies · Rook-Ceph

Infrastructure

Compute and storage in the provider’s cloud

The service

Three plans.
One operator.

1,200+ clusters in three plans, each declared once and run by the same CloudNativePG operator.

Development / one instance

For testing.

One instance, daily base backups and continuous WAL archiving.

Production / three instances

A primary and two standbys.

Streaming replication across nodes, with automatic failover.

Business-critical / synchronous

No data loss on failover.

A synchronous replica, longer retention and dedicated nodes.

Observability

Prometheus · Grafana · PostgreSQL exporters

Replication lag, connections, storage and backup age for every database.

Alert rules and runbooks cover failover, storage and backup failures.

Security

Per-tenant namespaces · Network policies · TLS · Vault

Encryption in transit, managed credentials and isolated tenant networks.

Database lifecycle

Every database follows
the same lifecycle.

From a request in the console to a restore at any point in time, each step is handled by the operator.

  1. 01

    Request

    API or console

  2. 02

    Provision

    CloudNativePG cluster

  3. 03

    Isolate

    Namespace and policies

  4. 04

    Replicate

    Primary and standbys

  5. 05

    Back up

    WAL archive and base backups

  6. 06

    Monitor

    Lag and health

  7. 07

    Upgrade

    Rolling, then switchover

  8. 08

    Restore

    Point in time

How high availability works

Each database runs as a primary with streaming standbys on separate nodes. If the primary fails, CloudNativePG promotes a standby and the service endpoint follows the new primary.

How backups and recovery work

WAL is archived continuously to S3-compatible object storage, alongside regular base backups. A database can be restored to any point within its retention window, and restores are rehearsed rather than assumed.

How upgrades roll out

Upgrades roll through the standbys first. The operator then switches over, so the old primary restarts last.

The outcome

Self-service for customers.
Calm for operators.

Databases became a product the provider sells, not a project its engineers run by hand.

01 / Customers

Databases without tickets.

Customers provision and manage databases themselves.

02 / Resilience

Routine failover.

Failover and recovery work the same way for every database.

03 / Operations

One way to run many.

Every database is declared, monitored and backed up by the same operator.

← All our work