Goal
Use the provided connection information correctly and avoid guessing at hidden runtime behavior.Prerequisites
- An existing database
Workflow
What operators can do from the database surface
- Open credentials on demand instead of keeping them permanently exposed
- Review or adjust pooler-related settings where supported
- Use clone and restore actions as separate recovery workflows
Connection pooling
Connection pooling is available for managed databases (a plan feature). When enabled, the database gets a pooler host and port you point your app at instead of the direct connection, which helps when many short-lived connections would otherwise exhaust the database.- Transaction mode: a connection is assigned for the duration of a transaction. This suits most applications.
- Statement mode: the most aggressive mode, assigning per statement — only for workloads that tolerate it.
- Enable or disable pooling from the database surface; when enabled, use the pooler host/port for app connections.
Direct vs pooled connections
Some clients and tasks (migrations, admin tools, anything needing session-level features) should use the direct connection; high-concurrency app traffic benefits from the pooler. Decide per consumer rather than assuming one connection string fits everything.Expected result
Your application connects to the database using the right credentials and expectations.
Related guides
Create a database
Provision a managed database and understand the minimum runtime and recovery expectations around it.
Back up and restore a database
Use the current S3-backed database backup and restore model with the correct operational expectations.
Database troubleshooting
Common issues around provisioning, connectivity, backup configuration, and restore progress.