Database

The platform provisions managed PostgreSQL for your services and applies your schema migrations as part of a deploy. Your data lives in a store you own — the platform layer does not own application data.

A service connects to its database through a binding resolved by the platform at deploy time, so application code never carries database credentials.

Migrations

A project's migration bundle is published to the put registry and applied before the new revision serves traffic. During a deploy this happens automatically; you can also publish a bundle directly:

putnami cloud publish-migration

Migrations are applied ahead of the release, so a revision never serves against a schema it was not built for.

Time-boxed access

Request a bounded, audited grant before connecting to a workload database. The bridge uses the platform path and does not require you to hold GCP credentials:

putnami cloud db grant request --database <name> --level read --reason "investigate incident"
putnami cloud db connect --database <name>

read, write, and maintain are the available grant levels. The server bounds the requested lifetime and records the reason.

Operator emergency access

The Cloud SQL Auth Proxy remains an operator/emergency path and needs GCP IAM. Prefer the audited database bridge above for ordinary support work:

putnami cloud sql-proxy --instance <project>:<region>:<instance> --port 5432

Next