Database routes and pooling

Self-hosted alpha.47 includes PostgreSQL, Redis and MongoDB. MySQL, ClickHouse, Oracle Database, Vitess, Neon and Supabase remain unavailable while native qualification is incomplete. Check the managed database guide for availability; these guides describe source behavior, not a production deployment.

Replication, routing and pooling answer different questions#

Replication controls copies and quorum. Routing chooses a destination. Pooling reuses a limited number of backend connections. Increasing one does not automatically improve the others.

A PostgreSQL application chooses read_write, read_only, pooled_read_write or pooled_read_only. PgBouncer does not inspect arbitrary SQL and move writes to the primary. Transaction pooling releases the server connection at transaction end; session pooling retains it for the session. Applications using session state must choose a compatible mode. Replica reads can lag.

MySQL Router likewise exposes different routes for primary and replica traffic. Redis and MongoDB clients must reach every advertised member needed for discovery and requests. A single reachable seed address does not establish that access. ClickHouse connection balancing does not invent a shard key or query every shard.

Redis Cluster advertises one set of member addresses. The public endpoint source preserves private discovery and allocates a separate TLS listener for each member. Outside clients must map the advertised private addresses to the corresponding public hostnames and ports, verify each certificate, and refresh the map when members change. A seed URI alone does not configure this. Public Redis access remains disabled until external routing, failover, source filtering and session revocation pass native acceptance.

The proposed Vitess contract uses declared integer hash sharding columns and SINGLE transaction mode. It must not promise cross-shard transactions or live resharding. Its controller, internal TLS, replication identity verification and recovery still need native acceptance. See Vitess configuration and runtime source.

Every route needs a retry policy. A broken connection after COMMIT does not prove the transaction failed. Reconnect with bounded retries, and use application idempotency for writes whose outcome is unknown.

Review the route before connecting#

1. Open the database and check that its observation belongs to the current revision. Investigate missing members or stale role observations first.
2. Choose the application service and connection variable. Choose the write, replica, pooled or cluster route intentionally.
3. Confirm that your driver supports that route. Redis Cluster needs redirection handling; MongoDB needs replica-set discovery; a private CA must be loaded where required.
4. Review the application revision, database revision and endpoint. Accept the review with the application's exact name, then follow the queued deployment.
5. Exercise a read and a write through the deployed application. For replica reads, check the application's consistency assumptions. Retry errors with a bounded policy.

For PostgreSQL, a reviewed direct binding uses:

[services.api.bindings.DATABASE_URL]
managed_database = "DATABASE_ID"
protocol = "postgres"
endpoint = "read_write"

To pool that connection, configure PgBouncer on the database and choose pooled_read_write. A replica route is not a new permission role. It changes where the connection goes, while the application account remains restricted to its own database.

Read the engine's contract#

See the PgBouncer feature matrix for pooling compatibility and the database architecture for process ownership and capacity.