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

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 and MySQL databases
• Insights and Backups actions for ready Valkey databases
• Insights actions for ready ClickHouse databases
• live CPU, memory, and disk snapshots for ready PostgreSQL, MySQL, Valkey, and ClickHouse databases

Engines available today

PostgreSQL

The PostgreSQL catalog currently includes these versions:

• 18.6
• 18.3
• 18.1
• 17.11
• 17.9
• 16.15
• 16.13
• 15.19
• 15.17

MySQL

The MySQL catalog currently includes these versions:

• 8.4.8.1 (default MOCO image; MySQL server 8.4.8)
• 8.4.3
• 8.0.40

Valkey

The Valkey catalog currently includes these versions:

• 9.1.2 (default)
• 9.0.2

ClickHouse

The ClickHouse catalog currently includes these versions:

• 26.8.2.7 (LTS)
• 26.4.5.143
• 25.12.12.1

ClickHouse versions are exact image tags, so every replica runs the same build. Installations created on 26.4 or 25.12 keep that version when you save other settings; changing the version requires a catalog version.

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

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 access over TLS through a public load balancer, the private MetalLB network, or a Tailscale endpoint (see External access)
• 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

The dedicated MySQL flow uses MOCO for replication and failover, with managed operations in Edka. See the MySQL guide for setup, connection, backup, restore, and maintenance instructions.

You can configure:

• 1, 3, or 5 instances, CPU and memory requests, and optional limits
• storage size and class, node-pool placement, taints, and replica spreading
• application users, databases, grants, and credential rotation
• validated MySQL parameters and slow-query logging
• external access over TLS through a public load balancer, the private MetalLB network, or a Tailscale endpoint; provisioned application users require TLS while external access is on
• scheduled and manual backups to saved Amazon S3 or S3-compatible storage
• snapshot or point-in-time restore into a new installation
• runtime metrics, planned switchover, rolling restart, and acknowledged upgrades

Storage can grow on an expandable storage class; it cannot shrink or change class in place. MySQL archives binary logs during backup runs, so point-in-time recovery is limited to confirmed archive intervals. Google Cloud Storage and Azure Blob Storage integrations are not supported MySQL backup targets.

ClickHouse capabilities

The dedicated ClickHouse flow provisions analytics clusters with ClickHouse Keeper coordination through the ClickHouse Operator.

You can configure:

• 26.8.2.7 (LTS), 26.4.5.143, or 25.12.12.1 server version, plus a separate Keeper version
• namespace and runtime name
• 1 to 5 server replicas per shard and the shard count, up to 16 server pods in total
• Keeper quorum size: 1, 3, or 5; topologies with more than one server pod require 3 or 5
• dedicated ClickHouse and Keeper storage sizes and storage classes
• a resource profile: Operator defaults, Small instance, or Production
• CPU and memory requests and memory limits for ClickHouse and Keeper pods; CPU limits are optional and empty by default
• node-pool placement and optional taint toleration
• default user password
• optional internal TLS between ClickHouse, Keeper, and in-cluster clients through cert-manager
• external access over TLS through a public load balancer, the private MetalLB network, or a Tailscale endpoint, on the HTTPS and secure native ports
• scheduled full backups to Amazon S3 or S3-compatible object storage, with Backup now and restore into a new installation
• runtime metrics and ClickHouse query workload insights

Current limitations:

• ClickHouse databases require Kubernetes v1.33 or later in Edka
• custom LoadBalancer source ranges are not supported yet
• backups are full snapshots; there is no point in time recovery
• Google Cloud Storage and Azure Blob Storage integrations are not available as ClickHouse backup targets

ClickHouse resource profiles

The Resources tab has a Resource profile field. New installations use Small instance. Both Edka profiles require a memory limit of at least 2048 MiB; they reserve 25% of that limit outside the ClickHouse server memory budget and cap the default user’s aggregate query memory at 50% of it. CPU and memory requests stay as entered.

Setting	Small instance	Production
Per-query memory	12.5% of the memory limit	25% of the memory limit
Sort and GROUP BY spill to disk	after 50% of per-query memory	after 50% of per-query memory
Query threads	1	1 per 2 GiB, up to 8, capped by the CPU limit when set
Concurrent queries	1 per 512 MiB, up to 4	1 per 512 MiB, up to 32
Mark cache	10% of memory, up to 512 MiB	10% of memory, up to 5 GiB
Uncompressed cache	off	off
Block size	8192 rows	65536 rows
Query, metric, asynchronous metric, and trace logs	kept 1 day	kept 7 days

For a 2048 MiB Small instance, the server budget is 1536 MiB, the default user can use 1024 MiB across all queries, each query is limited to 256 MiB, and sorts spill to disk after 128 MiB. The aggregate budget can reject queries before the concurrency limit is reached.

The profile applies to the default ClickHouse user profile. Profiles you create in SQL need their own limits. Spilled data goes to the ClickHouse data volume, so keep free space for it. Select Operator defaults to run without these overrides.

High availability

For an installation that survives a single worker failure, use one shard, 3 server replicas, and 3 Keeper replicas on at least three workers. Each replica gets its own volume, so three servers and three Keepers at 10 GiB each provision 60 GiB. Placement in one datacenter protects against a worker failure, not loss of the datacenter.

Replicas share row data only for tables in the ReplicatedMergeTree family. The Replicated default database synchronizes table definitions across replicas; it does not convert plain MergeTree tables into replicated ones.

Writes acknowledge on one replica by default. Set insert_quorum=2 to have a write acknowledged on two of three replicas, which keeps inserts flowing while one server restarts. Clients must reconnect after a connection drop and retry with a bound. Retry an insert only with a stable insert_deduplication_token for that insert, so a retry after a lost acknowledgement does not duplicate rows. The Kubernetes Service does not replay failed queries.

Creation reports how many Keeper and server replicas are ready in the status message and fails if the runtime is not ready within 20 minutes.

Upgrading ClickHouse and Keeper

Change ClickHouse version on the General tab of Settings to upgrade the server. Upgrade Keeper in a separate save: once the server upgrade completes, set Keeper version. Keep current version leaves Keeper untouched. Keeper 26.8.2.7 is the only upgrade target today.

Downgrades are rejected. An upgrade that jumps a year or more of releases, for example 25.12 to 26.12, needs an intermediate version.

The database shows Updating while a version or configuration change applies. The operator restarts one server replica at a time and waits for it to become ready before moving to the next. During each restart the server waits up to 60 seconds for running queries to finish, within a 90-second pod termination window. Longer queries are cancelled, and new connections can still land on a pod that is shutting down, so client reconnects and retries remain necessary during an upgrade.

ClickHouse backups and restore

ClickHouse backups are full snapshots of the application databases, written with native BACKUP ... ON CLUSTER to a bucket you own. System databases, server configuration, and users and roles created in SQL are not included.

Prerequisites:

• an Object Storage integration with the Amazon S3 or S3-Compatible provider
• a ClickHouse database in the Ready state

To enable scheduled backups:

1. Open the database, select Settings, then the Backup tab. The same tab is available when creating a database.
2. Turn on Scheduled backups.
3. Select the integration under Backup storage.
4. Set Backup interval (hours), from 1 to 168. The default is 24.
5. Set Retention (days), from 1 to 365. The default is 7.
6. Save. The first backup starts at the next full hour (UTC), and later ones follow the interval.

Snapshots are stored under clickhouse/<organization>/<installation>/backup-<uuid>/ in the bucket. Retention removes expired snapshots unless a restore still uses them. The schedule runs as a Kubernetes CronJob in your cluster and talks to ClickHouse directly, so backups keep running while Edka is unreachable.

The Backups tab shows the last backup, schedule, retention, and storage target, followed by the snapshot list: snapshot time and short id, status with the failure message when a backup did not complete, duration, and expiry. Backup now takes an extra full backup to the same destination without shifting the schedule, and is available while no other backup is running. When backups are off, the tab shows Off and a Backup settings link.

To restore a snapshot:

1. On the Backups tab, select Restore on a completed snapshot.
2. Keep or change the Name, which defaults to <source>-restored, and the Namespace.
3. Select Restore. Edka opens the new installation; it becomes Ready once ClickHouse confirms the restore.

Restore always creates a separate installation and leaves the source unchanged. The new installation uses the snapshot’s ClickHouse version, replica and shard counts, and storage size, and gets a new default user password.

You can also start a new database from a snapshot: on the Backup tab of the create form, choose it under Restore from backup. The list includes snapshots from deleted installations, so this is also how you recover a database after deleting it. Organization administrators additionally see snapshots taken in other clusters of the organization; the target cluster needs the snapshot’s storage class. The storage size cannot be smaller than the snapshot’s.

Troubleshooting:

• A failed restore is not retried in place. Delete the failed installation and start a new restore.
• After rotating the integration’s access keys, open Settings and save so the installation picks up the new credentials. Until then, backups fail with a reapply instruction.
• A backup that cannot confirm completion within 24 hours is marked failed. Its objects stay in the bucket for investigation instead of being deleted by retention.
• The ch-backup-<installation-id> CronJob in the database namespace runs the schedule. Check its Jobs with kubectl when a scheduled backup did not start.

Valkey capabilities

Run Valkey for caches, queues, or durable key-value storage on your own cluster. Choose 9.1.2 (default) or 9.0.2, standalone or a primary with up to three replicas, and optional automatic failover through Sentinel.

Persistence, memory, and storage

Choose none, rdb, or rdb + aof persistence. New durable installations default to RDB + AOF with appendfsync everysec and a dataset memory budget of 50% of the container memory limit. Ephemeral caches default to 80%. The budget is configurable from 10% to 80%, leaving room for replication and persistence work. CPU and memory requests are separate from limits.

Persistent installations have configurable storage size, storage class, node-pool placement, and taint toleration. Storage can grow when the actual StorageClass supports expansion. Shrinking or removing persistent storage is blocked. Persistence changes are maintenance operations: Edka copies or converts the data, validates it, and resumes client access when the target is ready. Plan for an interruption during these changes.

Replication and automatic failover

Replication can expose an optional read service. Enable Automatic failover to let three persistent Sentinels elect a primary with quorum two. It requires:

• ACL authentication
• a primary and at least two replicas
• a separate schedulable worker node for each data instance

Sentinels also spread across separate nodes. Disruption budgets protect planned drains. Applications keep the same service endpoint, but clients must reconnect after a promotion. Write-safety settings require recently responsive replicas; replication is asynchronous, so acknowledged writes can still be lost during failures. This is not a zero-data-loss guarantee.

Replica growth retains existing data pods. Before a scale-down removes the current primary, Edka waits for retained replicas to catch up and moves the primary. Apply version, port, or credential changes separately from reducing replicas. Once enabled, failover cannot be disabled in place; restore into a new installation to change that topology. Name, namespace, and the choice of standalone or replicated topology are fixed after creation.

Connections and TLS

External access requires ACL auth. Valkey serves the database hostname’s certificate on a separate TLS listener, and the external endpoint targets that listener. Application clients use a rediss:// URI with the hostname from Overview; redis-py and ioredis verify certificate and hostname with the system trust store. valkey-cli --tls checks the chain only. See External access.

Private MetalLB exposure supports source CIDR restrictions. Public Hetzner load balancers do not support these restrictions; Edka rejects that combination. Tailscale exposure uses tailnet access rules.

The internal service stays plaintext for managed applications on the same port as before. Enabling external access does not change their service address or credentials. Reapply connected applications after changing the Valkey password or port. Custom ACL user sets, external secret references, and raw valkey.conf overrides are not exposed in the Databases form.

Backups

1. Save an S3-compatible object storage integration.
2. Open the Valkey create form or Settings, then Backup. Enable backups and select Backup storage.
3. Set an interval of 1–168 hours, retention of 1–365 days, and enough Workspace (Gi) for the snapshot. The defaults are 24 hours and 7 days.
4. Save the backup settings.

Scheduled snapshots run inside your cluster on the hour in UTC, using a saved interval between attempts. Backup now on the Backups tab starts a manual job when backups are enabled and the installation is ready. Snapshot execution does not require Edka to remain continuously connected; Edka imports results into the catalog and manages retention.

Backups copy an RDB snapshot from the primary into your object storage. Storage credentials need object read, write, delete, and list permissions, plus multipart upload and abort permissions. Backup jobs use temporary snapshot storage and have a 24-hour deadline. Restore validates the saved snapshot against its manifest and checksum before loading it.

Deleting an installation removes its backup execution resources but preserves the backup catalog and stored snapshots, subject to retention.

Restore a snapshot

On Backups, select Restore for a completed snapshot. Choose a new installation name, destination storage class, and sufficient storage, then select Restore. You can also use Restore from Backup in the create form, including snapshots from deleted installations. Organization administrators can select snapshots from other clusters in the organization.

Restore creates a separate installation at the recorded Valkey version and leaves the source unchanged. Edka verifies the snapshot before loading it, provides memory and storage headroom, and synchronizes replicas from the restored primary. The copy receives fresh credentials and starts with internal access and backups disabled; configure these after recovery.

Restore recovers the selected RDB snapshot. Writes made after that snapshot are not included, and point-in-time recovery is not available for Valkey.

To test a backup, restore it into a new installation, check the recovered data, and delete that test installation when finished.

Monitoring and alerts

The Valkey exporter is enabled automatically. Insights shows resource usage, logical key counts from the observed primary, per-instance rates, and replica synchronization health. With failover enabled, Overview also shows Sentinel readiness.

With VictoriaMetrics installed, open Observability → Alerts → Packs and install Valkey. Its ten editable rules cover availability, memory and connection pressure, rejected connections, replica connectivity and traffic, RDB and AOF failures, and missing core metrics. It uses the existing exporter; no additional collector is needed. See the Valkey alert pack for thresholds and coverage.

Per-database pages

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

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

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.
• MySQL includes connection pressure, query throughput, and replication signals, with exporter metrics and history through VictoriaMetrics when available.
• Valkey counts logical keys from the observed primary, calculates rates per instance before aggregation, and reports replica synchronization health. With failover enabled, the overview also reports Sentinel readiness.
• ClickHouse includes runtime and query workload signals backed by VictoriaMetrics.

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

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. ClickHouse, MySQL, and Valkey restores start from the Backups tab and also create a new installation.

Users & DB

PostgreSQL and MySQL also expose a Users & DB tab for the managed objects on that runtime: provisioned users, databases, and their access configuration.

Backups

PostgreSQL and MySQL expose a Backups tab for backup snapshots and point in time recovery for that database. ClickHouse exposes a Backups tab for full snapshots, Backup now, and restore into a new installation. Valkey provides RDB snapshots, Backup now, and snapshot restore into a new installation.

Pooler

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

External access

Every engine shares one external access model. In the database settings, turn on External Access, pick a Network, and set the port clients connect to (ClickHouse has an HTTP port and a Native port).

Network	Reachability
Public load balancer	A public IP on a Hetzner load balancer, reachable from the internet.
Private network	An IP in the cluster’s private network, reached through private routing.
Tailscale	An endpoint on your tailnet.

Edka assigns the database a hostname under e2db.net, such as orders-0a1b2c3d.e2db.net, issues a Let’s Encrypt certificate for it inside your cluster, and publishes the hostname’s DNS record once the endpoint has an address. The database serves that certificate itself. Clients verify it with the trust store they already have; there is no certificate authority to download.

Overview shows the hostname in the connection details and a verified client command for the engine:

• PostgreSQL: psql "host=<hostname> port=<port> dbname=<db> user=<user> sslmode=verify-full sslrootcert=system" (sslrootcert=system needs a PostgreSQL 16 or later client)
• MySQL: mysql --host=<hostname> --port=<port> --ssl-mode=VERIFY_IDENTITY --ssl-ca=<system bundle>
• Valkey: a redis-py example with ssl=True, ssl_check_hostname=True, ssl_cert_reqs="required". valkey-cli --tls checks the chain but not the hostname; client libraries verify both by default.
• ClickHouse: clickhouse-client --secure --host <hostname> --port <native port>

Two clients bring their own certificate list instead of the system store. The MySQL CLI needs --ssl-ca pointed at the operating system bundle, for example /etc/ssl/cert.pem on macOS. TablePlus needs the same bundle in its SSL path field. Other MySQL connectors, GUI clients, and the other three engines’ clients use the system store on their own.

The hostname keeps its certificate while the database exists, so turning external access off and on again does not change it. Deleting the database removes the hostname and its DNS record. With a Tailscale or private-network endpoint the DNS record holds a tailnet or private IP; resolvers that block those ranges through rebind protection need an exception for e2db.net.

Automatic dependencies

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

PostgreSQL dependencies

• cert-manager
• cloudnative-pg
• edns-webhook when external access is enabled
• tailscale-operator when Tailscale is selected
• metallb when the private network is selected
• barman-cloud-cnpg-plugin when backups are enabled

MySQL dependencies

• cert-manager
• moco
• edns-webhook when external access is enabled
• tailscale-operator when Tailscale is selected
• metallb when the private network is selected

ClickHouse dependencies

• cert-manager
• clickhouse-operator
• edns-webhook when external access is enabled
• tailscale-operator when Tailscale is selected
• metallb when the private network is selected

Valkey dependencies

• cert-manager and edns-webhook when external access is enabled
• tailscale-operator when Tailscale is selected
• metallb when the private network is selected

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

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.

Related docs

• MySQL setup and operations
• Object Storage
• Cluster Observability
• Kubernetes App Templates
• Updating a Kubernetes Cluster
• Kubernetes Add-ons Management