Databases FAQ

Short answers about using databases.

Can I get a deleted database back?

Not yourself. Deleting a database removes it immediately. Its storage is kept for 7 days for support-assisted recovery, then permanently deleted. If you delete one by mistake, email support@kupe.cloud straight away with the tenant and database name.

Deletion protection is on by default, so a delete has to be preceded by deliberately turning it off.

Does removing a binding revoke access?

Removing a binding, or a namespace from one, takes the Secret, the Service and the network path out of that namespace. It does not change the password, so anything that read the Secret still knows it. Unbinding is not revocation: rotate the role’s credentials afterwards.

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

Rotation changes the password for every binding of that role, so applications in other namespaces with the same role pick up the new one too: from the updated mounted files, or after a restart if they hold it in memory.

Sessions that were open when the binding was removed are not closed. They stop getting responses and hang until the client’s TCP timeout. Set tcp_user_timeout or keepalives_* in your driver if you need them to fail quickly. See Removing access.

Can I upgrade to a newer PostgreSQL major version?

No. A database stays on the major it was created with, and the API, the CLI and Terraform all refuse a version change. Pick the major you want to keep when you create it. Kupe applies minor releases. Contact support if you need help planning application compatibility.

To move to a newer major today, create a new database on it and move your data across yourself.

How many bindings can one database have?

As many as fit in 20 namespaces. The bindings of one database list at most 20 namespaces between them, counting bindings still being deleted, and one binding lists at most 10. A namespace counts once for each binding that lists it, so 20 is enough for six namespaces with all three roles. Past that, split the work across databases. See Limits.

How many connections can my application open?

Each role has a connection limit set by the instance’s memory: one connection per 48 MiB, between 10 and 31. That is 10 at 512Mi, 21 at 1Gi, and 31 from 1536Mi up. All bindings of a role share its limit, so two Deployments bound with the readwrite role into different namespaces draw from the same 21 connections on a 1Gi database. Size your connection pools to fit, or raise the database’s memory.

There is no built-in connection pooler.

Can I get a superuser?

No. The three roles are app_owner (bound as owner), app_readwrite (bound as readwrite) and app_readonly (bound as readonly), and none is a superuser. None can create roles or databases. The owner role owns the database and can do anything a database owner can do inside it.

Can I give a reporting tool read-only access?

Yes. Bind the readonly role into the tool’s namespace. It reads every table the owner creates and can build temporary tables of its own, with a password of its own. It cannot write to the owner’s tables, call the owner’s functions or create large objects. See Read-only access.

Can I create more roles or more databases inside the instance?

No. Each Kupe database holds one PostgreSQL database and exactly those three roles. If two applications need separate credentials or separate data, give each its own Kupe database.

Can I install extensions?

There is no way to declare extensions. No role is a superuser, so the owner role can only run what PostgreSQL allows a database owner to run without one.

Can I connect without TLS?

No. Connections without TLS are refused. Bindings hand you sslmode=verify-full and the CA, and the server certificate names the database’s Service in each bound namespace, so full verification works.

Can I reach a database from outside my clusters?

No. Only pods in a bound namespace of a bound cluster can connect. There is no public endpoint.

Can I see the password?

Not in the console, the CLI or the API. It is only in the binding Secrets inside your clusters:

kubectl -n orders-api get secret orders-db-readwrite -o jsonpath='{.data.password}' | base64 -d

What happens to a database when I delete a cluster?

Nothing. The database is unaffected, and its bindings into that cluster wait. Create a cluster with the same name and they deliver again on their own.

Why can I not delete my tenant?

A tenant with databases cannot be deleted, with or without --cascade. Delete each database first; this keeps deletion protection in force on every one of them.

Why is my binding Pending?

Its database or its cluster does not exist yet, is not running yet, or is being deleted, or one of its namespaces has not been delivered into yet. The binding becomes Ready on its own once both are running. kupe database binding get shows the message and each namespace’s phase.

Why is my binding Failed?

One of its namespaces already holds a Service or Endpoints object named after the database, or a Secret with the binding’s Secret name, that the platform did not create. Kupe never overwrites it, and the binding’s other namespaces keep working. Remove or rename your object, take that namespace out of the binding, or delete the binding and add it again with another Secret name.