Skip to content
Edka infrastructure automation platform Edka infrastructure automation platform Edka
SYS.DOCS // DOCS

Dedicated Databases Workspace

The Databases workspace is the dedicated control surface for first-party database runtimes in a cluster.

These runtimes run on your own cluster. Edka provisions them and orchestrates operator-backed lifecycle automation in-cluster, but you keep full control of the infrastructure — it is not a separate hosted database service.

Open Clusters → Databases. This surface is independent from Apps and is where Edka exposes database-specific inventory, lifecycle, logs, insights, restore, and settings.

Inventory and lifecycle

Section titled “Inventory and lifecycle”

The landing page shows the database inventory for the cluster.

For each database, Edka exposes:

  • engine, version, lifecycle, and current status
  • provisioning progress while the runtime is queued or reconciling
  • quick actions for Open, Logs, Settings, and delete
  • Insights and Backups actions for ready PostgreSQL databases
  • Insights actions for ready Valkey and ClickHouse databases
  • live CPU, memory, and disk snapshots for ready PostgreSQL, Valkey, and ClickHouse databases

Engines available today

Section titled “Engines available today”

PostgreSQL

Section titled “PostgreSQL”

The PostgreSQL catalog currently includes these versions:

  • 18.3
  • 18.1
  • 17.9
  • 16.13
  • 15.17

MySQL

Section titled “MySQL”

The MySQL catalog currently includes these versions:

  • 8.4.3
  • 8.0.40

Valkey

Section titled “Valkey”

The Valkey catalog currently includes these versions:

  • 9.0.2

ClickHouse

Section titled “ClickHouse”

The ClickHouse catalog currently includes these versions:

  • 26.4
  • 25.12

Other planned catalog entries still reserved in the Databases surface include Redis, Kafka, and OpenSearch, but those engines remain marked coming soon.

PostgreSQL capabilities

Section titled “PostgreSQL capabilities”

The dedicated PostgreSQL flow has the richest engine-specific operations today.

You can configure:

  • 1, 3, or 5 instances
  • a data volume plus an optional dedicated pg_wal volume
  • bootstrap database, bootstrap user, and superuser credentials
  • node-pool placement and optional taint toleration
  • a CloudNativePG PgBouncer pooler
  • external exposure through a public LoadBalancer, private MetalLB LoadBalancer, or private Tailscale endpoint
  • backups to S3 compatible storage or Google Cloud Storage
  • restore to a new database from point in time recovery or a completed backup
  • import from an external PostgreSQL source with pg_dump and pg_restore options
  • declarative roles, databases, and extensions, pg_hba, pg_ident, and custom PostgreSQL parameters

MySQL capabilities

Section titled “MySQL capabilities”

The dedicated MySQL flow focuses on the core MOCO runtime surface.

You can configure:

  • 1, 3, or 5 instances
  • storage size and runtime version
  • bootstrap database and bootstrap user
  • optional custom admin and writable passwords
  • optional external exposure with a MySQL LoadBalancer service

From Settings, you can update runtime version, replica count, storage size, exposure, and password mode.

Storage class selectors mark default and node-local classes. For database workloads, Edka prefers the default non-node-local class when one is available so volumes are not accidentally tied to a single node.

Current limitations:

  • restore is not available for MySQL in Databases yet
  • backup automation is not yet wired through the dedicated MySQL form
  • PostgreSQL has broader insights coverage than MySQL today

ClickHouse capabilities

Section titled “ClickHouse capabilities”

The dedicated ClickHouse flow provisions analytics clusters with ClickHouse Keeper coordination.

You can configure:

  • 26.4 or 25.12 runtime version
  • namespace and runtime name
  • server replicas per shard and shard count
  • Keeper quorum size: 1, 3, or 5
  • dedicated ClickHouse and Keeper storage sizes and storage classes
  • CPU and memory requests and limits for both ClickHouse and Keeper pods
  • node-pool placement and optional taint toleration
  • default user password
  • optional internal TLS certificates through cert-manager
  • optional public LoadBalancer, private MetalLB LoadBalancer, or Tailscale exposure
  • runtime metrics and ClickHouse query workload insights

Current limitations:

  • ClickHouse databases require Kubernetes v1.33 or later in Edka
  • restore is not supported for ClickHouse in Databases yet
  • public LoadBalancer exposure requires TLS to be enabled and required
  • custom LoadBalancer source ranges are not supported yet

Valkey capabilities

Section titled “Valkey capabilities”

The dedicated Valkey flow is designed for cache-first or durable key-value workloads.

You can configure:

  • 9.0.2 runtime version
  • standalone or primary + replicas topology
  • cache-first or durable usage posture
  • persistence mode: none, rdb, or rdb + aof
  • storage size and storage class when persistence is enabled
  • CPU and memory requests and limits
  • node-pool placement and optional taint toleration
  • optional managed ACL auth for the required default user
  • optional read service for replication mode
  • write-safety thresholds for replicated topologies
  • external exposure through a LoadBalancer, private MetalLB LoadBalancer, or Tailscale endpoint
  • runtime metrics and exporter-backed insights

Current limitations:

  • restore is not available for Valkey in Databases yet
  • backup automation is not exposed in the Databases form today
  • TLS, custom ACL user sets, secret references, and raw valkey.conf overrides are intentionally deferred in the Databases surface for now
  • Valkey exposes Overview, Insights, Logs, and Settings tabs, but not PostgreSQL-specific Users & DB, Backups, or Pooler flows

Per-database pages

Section titled “Per-database pages”

Each database has its own workspace. Valkey and ClickHouse expose four tabs — Overview, Insights, Logs, and Settings. PostgreSQL and MySQL additionally expose Users & DB and Backups tabs, and PostgreSQL exposes a Pooler tab when the CloudNativePG pooler is enabled.

Overview

Section titled “Overview”

The Overview tab focuses on runtime topology and access:

  • runtime resource name and namespace
  • services and published endpoints
  • backup, replication, and pooler state when available
  • engine-specific managed-object and extension details

Insights

Section titled “Insights”

The Insights tab surfaces live runtime metrics where available.

  • PostgreSQL includes the richest coverage today, including history, connection pressure, throughput, cache hit ratio, and replica lag.
  • Valkey includes live runtime and exporter-backed signals for the managed Valkey database runtime.
  • ClickHouse includes runtime and query workload signals backed by VictoriaMetrics.

Logs

Section titled “Logs”

The Logs tab is a runtime pod log viewer with:

  • pod and container selection
  • tail-size selection
  • current or previous container logs
  • copy and download actions

Settings

Section titled “Settings”

The Settings tab provides the engine-specific edit form and the destructive delete flow for that database.

Ready PostgreSQL databases also expose a Restore action that always creates a new restored database instead of modifying the source in place.

Users & DB

Section titled “Users & DB”

PostgreSQL and MySQL also expose a Users & DB tab for the managed objects on that runtime — provisioned PostgreSQL users and databases.

Backups

Section titled “Backups”

PostgreSQL and MySQL expose a Backups tab for backup snapshots and point in time recovery for that database.

Pooler

Section titled “Pooler”

When the CloudNativePG pooler is enabled, PostgreSQL exposes a Pooler tab showing PgBouncer runtime and traffic signals for the database.

Automatic dependencies

Section titled “Automatic dependencies”

Database provisioning installs engine dependencies as part of the lifecycle flow.

PostgreSQL dependencies

Section titled “PostgreSQL dependencies”
  • cert-manager
  • cloudnative-pg
  • tailscale-operator when Tailscale exposure is selected
  • metallb when private MetalLB exposure is selected
  • barman-cloud-cnpg-plugin when backups are enabled

MySQL dependencies

Section titled “MySQL dependencies”
  • cert-manager
  • moco

ClickHouse dependencies

Section titled “ClickHouse dependencies”
  • cert-manager
  • clickhouse-operator
  • tailscale-operator when Tailscale exposure is selected
  • metallb when private MetalLB exposure is selected

Valkey dependencies

Section titled “Valkey dependencies”
  • tailscale-operator when Tailscale exposure is selected
  • metallb when private MetalLB exposure is selected

These dependency installs appear inside the database provisioning progress while Edka reconciles the runtime.

Databases vs Apps

Section titled “Databases vs Apps”

Use Databases when you want to provision a PostgreSQL, MySQL, Valkey, or ClickHouse runtime on your own cluster with engine-specific operations such as restore, runtime logs, connection details, managed objects, and engine-aware settings.

Use Apps for packaged application stacks and other app-like services that belong in the application catalog rather than the dedicated database inventory.

Section titled “Related docs”