Databases

Ownkube provisions managed PostgreSQL in one click on Ownkube-hosted compute. Backups, encryption, and connection pooling are included, and a new database is private by default. You never wire them up yourself.

Add one from your dashboard by choosing Database as the resource type.

Supported engines

PostgreSQL

Available now. Versions 17 and 18. Connection pooling, automated backups, and point-in-time recovery on EKS.

Valkey cache

Available now. In-memory, Redis-compatible cache for caching, sessions, and background queues, provisioned the same way as a database.

MySQL

Coming soon. Managed MySQL alongside PostgreSQL.

What you configure

Pick an engine and version

PostgreSQL 17 or 18. Pin the version. You can upgrade later through the detail page.
Size the database

Pick the CPU, memory, and storage you need. Start small; you can resize without destroying the database.
Pick an environment

Tag the database to an environment like Development or Production. On Ownkube-hosted compute that’s all you choose. In your own cloud you also pick a cluster: databases on Production clusters get HA by default; a Starter cluster (K3s on one AWS instance) runs a single PostgreSQL instance.
Create

Ownkube provisions the database, generates credentials, and attaches them to the deployment as environment variables.

High availability: primary + replica with automated failover
Point-in-time recovery: restore to any moment in the last retention window
Connection pooling: optional transaction or session pooling
Automated backups: daily snapshots with configurable retention
Vertical and horizontal scaling without downtime

Security defaults

Encryption at rest and in transit: data is encrypted at rest and reached over TLS. In your own cloud, at-rest encryption uses AWS KMS keys in your account.
Private by default: a new database has no public endpoint, reachable only from your own deployments. Public access is opt-in (see below).
Per-database credentials: each database gets its own generated user and password, held in the runtime secret store

Connecting your app

When you attach a database to a deployment, Ownkube injects a connection string and individual credentials as environment variables into your app container:

DATABASE_URL=postgresql://user:pass@host:5432/dbname
PGHOST=...
PGPORT=5432
PGUSER=...
PGPASSWORD=...
PGDATABASE=...

You don’t manage the secrets. Rotation happens automatically and the new values are picked up on the next rollout.

Public access

A database is private by default. If you need to reach it from outside the private network, for example from a local tool or a CI runner, turn on public access from the database’s Database tab. When you enable it, Ownkube:

allocates a stable public hostname for the database
issues a dedicated TLS certificate for that hostname
routes traffic to the database over an encrypted, TLS-passthrough connection

Connect with TLS verification on. Because several databases can share the public entry point, your client must send the hostname during the TLS handshake (direct TLS negotiation). For example, with psql:

psql "host=db-yourname.ownkube.app port=5432 dbname=app user=app sslmode=verify-full sslnegotiation=direct"

Backups

Automated backups are included on every managed database, encrypted at rest. In your own cloud they land in your own account:

Managed EKS (Production): daily automated snapshots with up to 30 days retention, stored encrypted in your S3
Starter (K3s on one AWS instance): scheduled snapshots at the frequency you choose, stored in your account

You can trigger a manual backup at any time from the deployment’s Database tab.

The Database tab

Every database deployment has a Database tab in your dashboard with:

Connection details: host, port, database, username, password (copy-friendly)
Connection string: single-click copy for DATABASE_URL
Backup status: last successful backup, next scheduled run
Resource usage: CPU, memory, and storage consumption

DB platform version

Every managed database runs on the DB platform version: the runtime Ownkube ships to power Postgres (and, soon, other engines). When we publish a new version with improvements, the deployment’s Database tab shows an Upgrade control.

Limits and constraints

MySQL is coming soon. See the changelog for progress.
Public access is off by default and opt-in per database (see Public access above).
In your own cloud, a deployment and its database should sit on the same cluster; cross-cluster access isn’t supported.

Deployments How databases fit alongside web apps, workers, and jobs.

Environment variables How generated database credentials reach your app.