Skip to content

Databases

Create a managed PostgreSQL database, then bind it to the cluster namespaces that need access. Start with Add a database.

A database belongs to your tenant. Deleting a cluster does not delete its databases.

Use Databases → Create Database in the console. Choose the PostgreSQL version, CPU, memory, storage, and optional high availability. Resources are per instance; HA uses two instances. Check Limits before sizing.

CPU and memory can change later. Storage can grow but cannot shrink. Resizing may interrupt connections, especially without HA. Configure your application to reconnect.

A binding gives one database role to one or more namespaces of a cluster. Choose the minimum access needed:

Role Use for
owner Migrations and schema changes
readwrite Applications reading and writing data
readonly Reports and read-only applications

Keep migration credentials in a separate namespace from your application.

Terminal window
kupe database binding add orders-db --cluster prod --namespace orders-api --role readwrite

Wait for the binding to become Ready. Each selected namespace receives:

  • a Service named after the database, on port 5432;
  • a credentials Secret named {database}-{role}, unless you choose another name.

Mount the Secret at /bindings/<secret-name> and set SERVICE_BINDING_ROOT=/bindings. Its uri key contains the connection string and expects that mount path. It also contains host, port, database, username, password, sslmode, ca.crt, type, and provider for clients that build their own connection settings. Keep sslmode=verify-full and use the supplied CA certificate.

A name such as orders-db becomes orders_db inside PostgreSQL. No role is a superuser.

Use the readonly role for reporting. It can read tables created by the owner, including future tables, but cannot change them.

Edit the binding in the console or run:

Terminal window
kupe database binding update orders-db orders-db-prod-readwrite --add-namespace orders-worker

Use --remove-namespace to remove a target. To change the cluster, role, or Secret name, replace the binding. A binding must retain at least one namespace.

Pending means a dependency is not ready. Ready means the Service and Secret are available. For Failed, read the message in the console; a conflicting Service or Secret may need renaming. Check each namespace’s status separately.

Only bound namespaces can connect. Anyone able to read credentials or run a pod in a bound namespace can use that role. Keep unrelated workloads out of those namespaces.

HA adds a standby for failover. It can be enabled or disabled after creation. Applications should retry interrupted connections. During a standby outage, the primary continues accepting writes without a second copy; keep independent backups.

Read credentials from the binding Secret in your cluster. All bindings for one role use the same password. Rotate through Settings → Rotate credentials, or run:

Terminal window
kupe database rotate-credentials orders-db --role readwrite

Wait for rotation to complete. Applications that load credentials or the CA only at startup must restart. Use Kupe’s rotation action rather than changing passwords with SQL, so binding Secrets stay current.

Remove a binding to remove its delivered credentials and access. This does not change the password: rotate the role afterwards if a former user should lose access permanently. Existing connections may take time to fail; use client timeouts.

Protection is on by default. Disable it in Settings before deleting a database. Deletion removes its bindings too. Storage is retained for 7 days for support-assisted recovery, then permanently deleted. There is no self-service restore.

Check database health in Grafana. Configure notifications for DatabaseStorageAlmostFull, DatabaseInstanceDown, and DatabaseUnavailable. Use a database label matcher to route them. Also check binding status when troubleshooting application connections.