# Databases > One-click managed PostgreSQL on Ownkube-hosted compute. Private by default, with backups, pooling, and encryption included. Ownkube provisions managed [PostgreSQL](https://www.postgresql.org/) 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**](https://app.ownkube.io/dashboard) by choosing **Database** as the resource type. **Running in your own cloud?** On the Advanced own-cloud path, the same one-click database runs inside your own AWS account: the data, backups, and encryption keys all stay in your VPC. The cluster-shape details below (Starter vs Production) and the AWS-account specifics apply there. ## 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 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](/docs/features/environments) 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. 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 and in transit**: data is encrypted at rest and reached over TLS. In your own cloud, at-rest encryption uses [AWS KMS](https://docs.aws.amazon.com/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: ```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 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`: ```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 over the private network for production traffic. ## 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](https://docs.aws.amazon.com/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](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 retained until their retention window expires (in your own S3, on the own-cloud path). If you need to preserve data, take a manual backup before deletion. ## 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](#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](/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.