Database overview

Provisioning

Creating a database issues a dedicated PostgreSQL role, a generated password and a connection limit. The database belongs to the project you created it in and is not reachable from another project's credentials.

veltic databases create PROJECT_ID orders
veltic databases list PROJECT_ID
veltic databases reveal PROJECT_ID orders

Two ways in

A direct TCP connection is the right choice for migrations, psql, ORMs and anything that needs session state. The HTTPS Data API is the right choice for serverless runtimes that cannot hold a socket. Both enforce the same row level security policies.

Connections are the scarce resource

PostgreSQL reserves a small number of connections for the superuser. Every role brings its own limit, and there is no shared ceiling that stops the sum of role limits from exceeding what the server can actually serve. The dashboard reports the sum and the amount of over-commitment; watch it before you raise a limit.

• Pool in your application rather than opening a connection per request.
• Raise a role limit only after checking the reported over-commitment.
• Long-running transactions hold connections; the SQL editor is no exception.

Rotating credentials

Rotation issues a new password for the existing role, so grants and ownership survive. Update your environment variables and redeploy; nothing else changes.