Databases

Ownkube provisions managed PostgreSQL databases directly inside the cluster in your AWS account. Backups, encryption, and connection pooling are included. 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.

Redis

Coming soon. In-memory store for caching, sessions, and background queues.

MySQL

Coming soon. Managed MySQL alongside PostgreSQL.

What you configure

1. Pick an engine and version

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

2. Size the database

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

3. Pick a cluster and environment

   Databases live on a cluster, tagged to an environment. Databases on Production clusters get HA by default; a Starter cluster (K3s on one AWS instance) runs a single PostgreSQL instance.

4. Create

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

Cluster-shape differences

EKS (Production)

• 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

K3s (Starter)

• Single instance: runs on the same node as your apps
• Automated backups: periodic snapshots stored in your account’s S3
• Best for dev, staging, and small production workloads where a single-AZ DB is acceptable
• Upgrade path: move workloads to EKS when you need HA

Security defaults

• Encryption at rest using AWS KMS keys in your account
• Encryption in transit via TLS
• Private by default: a new database is reachable only from inside your VPC, with no public endpoint. Public access is opt-in (see below).
• Per-database credentials: each database gets its own generated user and password, stored in your cluster’s 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 VPC, 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"

Caution

Public access widens your exposure. Keep it off unless you need it, use the generated credentials, and prefer connecting from inside the VPC for production traffic.

Backups

• Managed EKS: 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

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.

Tip

Keep up to date. Staying on the latest DB platform version is how you get new engine features and reliability improvements as they ship. We’ll let you know in-app when an upgrade is available and what changed. Upgrades are designed so they don’t affect deployment quality. Rollouts use drain-safe swaps so your database stays reachable.

Caution

Deleting a database deployment removes the data. Backups are kept in your S3 until their retention window expires. If you need to preserve data, take a manual backup before deletion.

Limits and constraints

• Redis and MySQL are coming soon. See the changelog for progress.
• Cross-cluster access isn’t supported. A deployment and its database should be on the same cluster.
• Public access is off by default and opt-in per database (see Public access above).

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

Environment variables How generated database credentials reach your app.

---

Note

Don’t see a feature you need? Email support@ownkube.io. Ownkube is shaped by the teams using it and we ship what our users ask for.