Skip to main content
Live. This area is documented as current, user-reliable behavior.

​
Goal

Connect each application through the correct stable endpoint and preserve that identity through recovery or transfer cutovers.

​
Prerequisites

  • An existing database

​
Workflow

1
Read the stable hostname, port, database name, username, and TLS details from the database page.
2
Choose direct or pooled access based on the consumer rather than assuming one endpoint fits every workload.
3
Keep private access by default and narrow any public allowlist and expiry.
4
Smoke-test through the same stable endpoint after restore, promotion, or rollback.

​
Stable connection details are authoritative

Use only the connection information displayed for the logical database. Do not infer a container name, node IP, physical generation, or hidden candidate address. Import candidates never expose credentials and never inherit public access.
  • Treat the stable hostname as the application-facing identity.
  • Use the required TLS mode and CA information shown by the product.
  • Retrieve credentials on demand and avoid copying them into tickets, logs, or documentation.
  • Use application bindings where available instead of manually reconstructing connection strings.

​
Connection pooling

Connection pooling is available where the database and plan support it. When enabled, the database exposes a pooler host/port for application traffic with many short-lived connections. The direct endpoint remains necessary for clients that depend on session-level behavior.
  • 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.
  • Migrations, administrative clients, session variables, prepared statements, and similar features may require direct access.

​
Private and public access

Public exposure is a policy applied around the stable database identity; it does not replace the private stable endpoint. Use the narrowest allowlist and expiry that works. Promotion and rollback reapply and verify the existing private/public hostname, allowlist or anywhere mode, proxy policy, and firewall policy before declaring cutover complete.

​
What transfer promotion preserves

  • Private and public hostname and port.
  • Database name, username/password identity, and credential fingerprint.
  • CA and TLS policy.
  • Allowlist or anywhere public-access mode.
  • Proxy and firewall policy.

​
Expected result

Applications use the correct stable connection identity and continue using it across physical generation changes.

​
Common failures

  • Using a stale copied connection string instead of reopening current database details.
  • Sending migration or session-dependent traffic through an incompatible pooler mode.
  • Pointing an application at a physical candidate or node address instead of the stable hostname.
  • Assuming public access is required when the application can use the private endpoint.

Create a database

Provision a managed database with the right engine, size, context, access, and hosted V2 expectations.

Import and export a database

Move complete PostgreSQL or MySQL databases as portable SQL with resumable uploads, private candidates, structural validation, explicit promotion, and 24-hour rollback.

Back up and restore a database

Use durable recovery storage correctly and understand why backups are independent from portable SQL transfers.

Database troubleshooting

Diagnose provisioning, stable connectivity, backup, upload, export, validation, promotion, download, rollback, and cleanup failures.