Skip to content
Ownkube

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

Section titled “Supported engines”

PostgreSQL

Available now. Versions 17 and 18. Connection pooling, automated backups, point-in-time recovery, and optional high availability.

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

Section titled “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 an environment

    Tag the database to an environment like Development or Production. That’s all you choose.

  4. Create

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

High availability

Section titled “High availability”

A managed database runs as a single instance by default. Turn on high availability to run a primary plus up to two standby instances (three total) with automatic failover and streaming replication, so a single node failing doesn’t take the database down. Each standby is billed as a reserved database instance.

High availability is available on Ownkube-hosted compute.

Security defaults

Section titled “Security defaults”
  • Encryption at rest and in transit: data is encrypted at rest and reached over TLS.
  • 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

Section titled “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:

Terminal window
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

Section titled “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:

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

Backups

Section titled “Backups”

Automated backups are included on every managed database, encrypted at rest, with point-in-time recovery so you can restore to any moment in the retention window. On Ownkube-hosted compute, backups run and are retained automatically.

You can trigger a manual backup at any time, and restore to a point in time, from the deployment’s Database tab.

The Database tab

Section titled “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

Section titled “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

Section titled “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).
Deployments How databases fit alongside web apps, workers, and jobs.
Environment variables How generated database credentials reach your app.