# Databases

> One-click managed PostgreSQL running inside your own AWS VPC. Backups, pooling, and encryption included.

Ownkube provisions managed [PostgreSQL](https://www.postgresql.org/) 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**](https://app.ownkube.io/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](/docs/features/environments). 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](https://docs.aws.amazon.com/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:

```bash
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`:

```bash
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](https://docs.aws.amazon.com/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](https://app.ownkube.io/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.

**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](#public-access) above).

- [Deployments](/docs/features/deployments)
- [Environment variables](/docs/guides/environment-variables)

---

**Don't see a feature you need?** Email [support@ownkube.io](mailto:support@ownkube.io?subject=Feature%20request). Ownkube is shaped by the teams using it and we ship what our users ask for.