SYS.DOCS // DOCS

Databases overview

Databases provisions PostgreSQL, MySQL, Valkey, and ClickHouse on your own cluster. Each database runs in a namespace of your cluster, on your nodes and volumes, and its backups go to a bucket you own. Edka is not a hosted database service. Disconnect Edka and the databases keep running.

Open the cluster and select Databases under Workloads.

Engines

Engine	Runs with	Guide
PostgreSQL	CloudNativePG	PostgreSQL
MySQL	MOCO	MySQL
Valkey	A Helm chart from `charts.edka.io`	Valkey
ClickHouse	ClickHouse Operator	ClickHouse

PostgreSQL. 1, 3, or 5 instances with synchronous replication and automatic failover, a PgBouncer pooler, WAL archiving with point in time restore, import from another PostgreSQL server, and provisioned users, databases, and extensions.
MySQL. 1, 3, or 5 instances with MOCO replication and failover, users and grants, scheduled and manual S3 backups, snapshot or point in time restore, planned switchover, rolling restart, and version upgrades.
Valkey. Standalone, or a primary with up to three replicas and optional Sentinel failover, for caches, queues, and durable key-value storage, with RDB snapshots to S3.
ClickHouse. Analytics clusters with ClickHouse Keeper, resource profiles, high availability, version upgrades, and full S3 snapshots.

Inventory

The Databases page lists the databases in the cluster. Each card shows the name, status, engine, version, age, topology, and storage. While a database is being created, updated, or deleted, the card shows the current phase and a progress bar. Ready databases show live CPU, memory, and disk usage.

The card menu has Open, Logs, and Settings for every database, Insights for ready databases, and Backups for PostgreSQL and MySQL. Delete reads Force delete while a database is still being created.

When your plan limits the number of databases in a cluster, the page header shows how many are in use.

Versions

PostgreSQL

18.6 (default)
18.3
18.1
17.11
17.9
16.15
16.13
15.19
15.17

MySQL

8.4.8.1 (default MOCO image, MySQL server 8.4.8)
8.4.3
8.0.40

Valkey

9.1.2 (default)
9.0.2

ClickHouse

26.8.8.8 (LTS, default)
26.4.5.143
25.12.12.1

ClickHouse versions are exact image tags, so every replica runs the same build. A MySQL or ClickHouse database on a version that has left this list keeps it when you save other settings. A version change has to pick a version from the list.

Database tabs

Tab	Engines	Shows
Overview	All	Health, connection details, and configuration
Insights	All	Live metrics and, for PostgreSQL, sessions and query statistics
Pooler	PostgreSQL with the pooler on	PgBouncer clients, servers, and traffic
Logs	All	Pod logs, streamed live
Users & DB	PostgreSQL and MySQL	Provisioned users and databases
Backups	All	Snapshots, Backup now, and restore
Settings	All	The engine form and the delete section

Overview

Runtime Status counts ready instances and names the primary. Where they apply, it adds the state of the pooler, replication, Sentinels, and the last backup. It lists operator conditions and warnings when the database is not healthy. ClickHouse shows a Health card instead.
Connection Details builds the connection parameters and connection string for a network and user, once the database is ready.
Verified connection shows the TLS client command for the engine, once external access is on and the certificate is issued.
Configuration has three panels. Runtime, named Topology for ClickHouse, shows the Kubernetes resource name, namespace, image, and placement. Resources shows storage, CPU, and memory. Access shows the exposure, endpoints, and backups.
MySQL adds Provisioned Objects when it has users or databases beyond the application user and database.
While Edka installs add-ons for the database, Lifecycle Status lists them.

Insights

Engine	Charts	Summary
PostgreSQL	Transactions, connections, CPU, memory	Connection capacity, cache hit, database size, replication lag
MySQL	Running queries, connections, CPU, memory	Connection capacity, buffer pool hit, running queries, replication lag
Valkey	Operations, keys, CPU, memory	Connections, cache hit, evictions, memory limit
ClickHouse	Queries, inserted rows, CPU, memory	Connections, active queries, running merges, disk used

PostgreSQL adds Current Connections and Query Statistics. ClickHouse adds Replication and operator details.

History comes from VictoriaMetrics when it is installed on the cluster. Without it, the charts cover the current browser session only. See Cluster Observability.

Logs

Logs streams the logs of the database pods. Select the pod and container, and a tail of 50, 100, 200, 500, or 1000 lines. Previous shows the logs of the previous container after a restart. Copy logs and Download logs export what is on screen.

Users & DB

PostgreSQL and MySQL list the users and databases Edka provisions, with their privileges and owners. Add and edit them on this tab, then save the page. MySQL has the same editor under Settings, on Users.

Backups

Engine	Backup	Restore
PostgreSQL	Base backups and continuous WAL archiving	A point in time or a base backup
MySQL	Snapshots and binary log archives	A snapshot, or a time inside an archived interval
ClickHouse	Full snapshots	A snapshot
Valkey	RDB snapshots	A snapshot

Backup now takes an extra backup when backups are on and the database is ready. A restore always creates a new database and leaves the source unchanged. PostgreSQL restores start from the source database’s Backups tab, so the source must still exist. MySQL, ClickHouse, and Valkey can also restore a snapshot of a deleted database from the Backup tab of the create form.

Settings

Settings holds the engine form. The delete section is at the bottom of General. Type delete me to confirm. Deleting removes the database, its volumes, its Kubernetes Secrets, and its hostname and certificate. Backups stay in your bucket.

External access

Every engine exposes a database the same way. On the Access tab of the create form or Settings, turn on External Access, pick a Network, and set the Port. ClickHouse has an HTTP port and a Native port instead. The default ports are 5432 for PostgreSQL, 3306 for MySQL, 6379 for Valkey, and 8123 and 9000 for ClickHouse.

Network	Reachability	Requires
`LoadBalancer`	A public IP on a Hetzner load balancer, reachable from the internet.	Nothing extra
`Private LoadBalancer`	An IP in the cluster’s private network, reached through private routing.	Private networking enabled on the cluster
`Tailscale`	An endpoint on your tailnet.	The Tailscale add-on installed and ready

Edka assigns the database a hostname under e2db.net, such as orders-0a1b2c3d.e2db.net. cert-manager in your cluster gets a Let’s Encrypt certificate for it, and the database serves that certificate itself. Clients verify it with the trust store they already have. There is no certificate authority to download.

Edka publishes the hostname’s DNS record once the endpoint has an address. If the address changes, for example after a load balancer is recreated, Edka updates the record within five minutes.

Overview shows the hostname in the connection details. Once the certificate is issued, Verified connection shows the 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> --user=<user> --password --ssl-mode=VERIFY_IDENTITY --ssl-ca="$SYSTEM_CA_BUNDLE" <db>
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.
ClickHouse: clickhouse-client --secure --host <hostname> --port <native port> --user default --ask-password

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 and GUI clients, and the clients of the other three engines, use the system store on their own.

The hostname and its certificate stay while the database exists. Turning external access off removes the DNS record, and turning it back on publishes the same hostname again. Deleting the database removes the hostname, its DNS record, and its certificate.

MySQL routes external traffic to the primary only after the certificate is loaded and TLS is enforced on its accounts. With a Tailscale or Private LoadBalancer endpoint, the DNS record holds a tailnet or private IP. Resolvers that block those ranges through rebind protection need an exception for e2db.net.

Add-ons installed with a database

Creating a database installs the add-ons it needs. While they install, Lifecycle Status on Overview lists them.

Engine	Always	With backups on
PostgreSQL	`cert-manager`, `cloudnative-pg`	`barman-cloud-cnpg-plugin`
MySQL	`cert-manager`, `moco`	None
ClickHouse	`cert-manager`, `clickhouse-operator`	None
Valkey	None	None

External access adds cert-manager and edns-webhook for every engine, and metallb for the Private LoadBalancer network. The Tailscale network uses the tailscale-operator add-on. Install it yourself first, because it needs OAuth credentials for your tailnet. See Tailscale and Private networking.

Databases and Apps

Use Databases for PostgreSQL, MySQL, Valkey, or ClickHouse with operations specific to the engine: restore, pod logs, connection details, provisioned users and databases, and version upgrades.

Use Apps for packaged application stacks from the app catalog.