The environments share the database through a transaction pooler
Table of Contents
1. Summary
The ten environments on one machine share one PostgreSQL instance. A pooler in transaction mode stands in front of it. Services connect to the pooler, and the pooler holds a capped number of server connections for each database and for the instance. A connection carries nothing between transactions (A transaction sets its own tenant context, so any connection serves any tenant) and statements are prepared through the protocol (A hand-written statement is declared once, typed both ways and prepared once), so a server connection serves any service of its environment from one transaction to the next.
2. Detail
2.1. The caps
| Cap | Set for |
|---|---|
| Server connections for each environment's database | the environment's peak concurrent transactions |
| Server connections for the instance | below max_connections, with room for direct connections |
A service's pool size (A service holds a few long-lived connections and never connects per query) is what the service may have open at once; the pooler's cap is what the environment may have running at once.
2.2. What connects directly
Work that needs a session goes around the pooler:
- the listener on
LISTENthatpostgres_event_sourceinores.eventingruns, which turns entity change notifications into events, - a lock held across transactions,
- the tick lanes (Ticks reach the store through sharded binary COPY in bounded batches), whose long COPY batches would hold a pooled server connection for their whole length.
2.3. Prepared statements
The pooler keeps protocol-level prepared statements on its server connections, so a statement prepared once stays prepared as transactions move between server connections.
3. See also
- The data path — the structure note that orders this cluster.
- PostgreSQL: Database Architecture and Conventions — the instance behind the pooler.