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.
Create and size a database
Section titled “Create and size a database”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.
Bindings
Section titled “Bindings”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.
kupe database binding add orders-db --cluster prod --namespace orders-api --role readwriteWhat appears in the cluster
Section titled “What appears in the cluster”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.
Read-only access
Section titled “Read-only access”Use the readonly role for reporting. It can read tables created by the owner,
including future tables, but cannot change them.
Changing the namespaces
Section titled “Changing the namespaces”Edit the binding in the console or run:
kupe database binding update orders-db orders-db-prod-readwrite --add-namespace orders-workerUse --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.
Binding status
Section titled “Binding status”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.
Network isolation
Section titled “Network isolation”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.
High availability
Section titled “High availability”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.
Credentials and rotation
Section titled “Credentials and rotation”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:
kupe database rotate-credentials orders-db --role readwriteWait 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.
Removing access
Section titled “Removing access”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.
Deletion protection
Section titled “Deletion protection”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.
Alerts
Section titled “Alerts”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.