Databases
One-click managed PostgreSQL running inside your own AWS VPC. Backups, pooling, and encryption included.
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
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 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.
Create
Ownkube provisions the database, generates credentials, and attaches them to the deployment as environment variables.
Cluster-shape differences
- 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
- 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"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 at app.ownkube.io/dashboard/deployment/:deploymentId 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.
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.
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.