Skip to main content

Managed databases

Teams provision PostgreSQL and MariaDB without operating the database engine themselves.

A tenant creates a database from a short manifest or a console form. Platform controllers manage the engine, replication, and backups. The tenant receives a stable endpoint and a Kubernetes Secret containing the credentials.

Engines and provisioning

PostgreSQL and MariaDB, in the versions published by the platform's catalog. A database is one resource:

apiVersion: db.kube-dc.com/v1alpha1
kind: KdcDatabase
metadata:
name: orders
namespace: acme-shop
spec:
engine: postgresql
version: "16"
databaseName: orders
username: app
cpu: "1"
memory: 2Gi
storage: 20Gi
replicas: 2
backup:
enabled: true
schedule: "0 2 * * *"
retentionDays: 7

The platform provisions the engine, storage and credentials from the manifest, exposing a stable in-project endpoint (orders-rw.<project>.svc for PostgreSQL; a primary-routing endpoint for MariaDB) and an auto-generated credentials Secret.

Topology and failover

  • 1 replica — standalone instance.
  • 2+ replicas — engine-level replication: PostgreSQL streaming replication; MariaDB primary–replica replication. With sufficient independent failure domains and capacity, instances schedule across separate hosts, and after an eligible primary failure the operator promotes an available replica automatically — recovery behavior depends on engine state and deployment topology, and the read-write endpoint follows the current primary.
Managed database availability and backup pathAn application connects through a stable read-write endpoint to the current database primary. The primary replicates to an available replica, which the operator can promote after an eligible failure. Scheduled and on-demand backups are written to Project S3 and can restore a database under a new name or in place.Applicationstable RW endpointPrimarycurrent writerReplicapromotion targetPROJECT DATA PROTECTIONProject S3 backupsscheduled + on demandKMS envelope when configuredRestore copynew nameIn-place restorecontrolled outage
Applications keep one read-write endpoint while engine replication and operator promotion protect service continuity; scheduled and on-demand backups land in Project S3 for new-name or in-place restore.

A practical note for multi-replica databases: the resource reports Ready when the service is available; check instance readiness before assuming full redundancy after creation or maintenance.

Credentials

  • Connection details and passwords are generated by the platform and delivered as Kubernetes Secrets — applications consume them as environment variables or mounted files; nothing is typed or emailed.
  • Credential-rotation policies rotate static passwords on a schedule and project the current credential into a stable Secret your workloads reference.

Backups

  • Scheduled backups per database — cron schedule and retention days in the manifest — written to the project's S3-compatible bucket.
  • On-demand snapshots any time, from the console or by creating a backup resource.
  • Per-database encryption: reference a project KMS key and backups are envelope-encrypted with a key that never leaves the platform's secrets backend.
  • For PostgreSQL, point-in-time recovery is available within the backup window where continuous archiving is enabled.
Managed PostgreSQL Backups tab showing a daily schedule, seven-day retention, S3 destination, manual backup action and completed backup history
Database protection is visible and operable from the service itself: schedule, retention, destination, on-demand backup and completion history share one view.

Restore

Two documented paths:

  • Restore into a new database (recommended): create a new KdcDatabase with spec.restoreFrom naming the backup — verify the recovered data, then switch applications over. The source database keeps running.
  • In-place restore (destructive): trigger by annotation on the existing database; the platform re-bootstraps it from the chosen backup. Plan a maintenance window — current data is replaced.

Configuration and lifecycle

  • Resources (CPU, memory) and engine parameters adjustable per database; some changes restart instances or trigger failover — applications should reconnect and retry.
  • Storage grows online (increase only).
  • Version changes are maintenance operations: verify a current backup first, then move.

Responsibilities

ConcernYour platform teamTenant
Engine operation, replication, failover✅ (controllers)
Backup execution and storageControllers execute scheduled backups✅ schedule/retention choice, on-demand runs
RestoreMechanism provided✅ initiates, verifies recovered data
Credentials delivery and rotation✅ application usage hygiene
Schema, queries, application-level integrity
Off-platform backup copiesS3 endpoints provided✅ via enterprise backup