Multi-Region PostgreSQL¶

An application running in one region and accessing PostgreSQL in another pays the link latency on every round trip. Because PostgreSQL keeps one process per connection and the protocol is conversational, the effect shows up twice: in the time of each query and in the cost of opening connections across the WAN.

The bottleneck is rarely the database. It is the distance — and the design that hides it.

InteSys works on every layer of this problem, from transparent optimizations for legacy systems to complete regional architectures with replication, caching and geographic distribution — operating in both Brazilian Tier III regions: br-sp-1 (Cirion SAO1, Cotia/SP) and br-sp-2 (Equinix SP3, Tamboré/SP).

The problem¶

Between br-sp-1 and br-sp-2 latency is a few milliseconds — both regions are in the São Paulo metropolitan area and interconnect through Lan2Lan links or encrypted tunnels. A Brazil ↔ United States link operates on a different order of magnitude, above a hundred milliseconds of RTT. That difference is what defines which queries can cross the WAN and which must be answered locally.

Goals of a regional architecture:

• reduce the number of queries that cross the WAN;
• bring reads and high-frequency data closer to the application;
• keep writes consistent and controlled;
• eliminate the cost of opening connections across the link;
• preserve compatibility with legacy applications;
• allow gradual evolution, without rewriting the system.

Architecture catalogue¶

1. Resilient connectivity between regions¶

Before touching the database, we stabilize the transport: redundant paths, VPNs, alternative routing and continuous observability of RTT, jitter and packet loss.

Recommended for: environments with packet loss or dependency on a single WAN path. Limitation: it does not remove the physical latency between regions.

2. Connection pooler close to the application¶

A PgBouncer installed in the application's region keeps persistent connections to the remote database and hands cheap local connections to the application. In PostgreSQL this matters even more than in other databases: every new connection is a new process on the server.

Recommended for: applications with many short connections, serverless, PHP and workers. Benefits: eliminates the handshake across the WAN, protects the database from connection spikes and creates a single observability point. Limitation: queries still travel to the remote region.

3. Read replica in Brazil¶

The primary stays where it is and a streaming standby is kept in br-sp-1 or br-sp-2, serving local reads in read-only mode.

Recommended for: applications with meaningful read volume and tolerance for eventual consistency on part of the queries. Benefits: local SELECTs with low latency and a significant drop in average response time. Watch out for: reads immediately after a write may need to go to the primary.

4. Read and write routing¶

The application talks to a local endpoint. The pooler separates reads from writes; the cache serves high-frequency data; the replica serves selected reads; the primary remains the only write authority.

Routing can be done in two ways, and both coexist well:

• In the application — two data sources, one -rw and one -ro. It is explicit, testable and avoids consistency surprises.
• In the proxy layer — the pooler exposes distinct ports for reads and writes, with no code change.

Benefit: progressive adoption, query by query, without betting everything at once.

5. Regional cache with Valkey/Redis¶

Repetitive data lives in a Valkey or Redis instance in the application's region: settings, profiles, permissions, catalogues, sessions, expensive query results and derived data.

Recommended for: data with a high read rate and a well-defined invalidation strategy. Benefit: the most frequent queries stop depending on the distance to the database.

6. Physical or logical replication¶

Physical replication copies the entire cluster and keeps the target read-only; logical replication replicates what was selected and keeps the target writable.

Logical replication is also the lowest-risk path to migrate a database to InteSys: it syncs in production and the cutover happens in a short window.

7. Regional API / data service layer¶

In new or modernized systems, the application stops running dozens of SQL statements across the WAN and instead calls a regional API that executes the transaction next to the database.

Benefit: trades several SQL round trips for a single business call.

8. Geographic sharding / regional ownership¶

Data is partitioned by customer, tenant, country or functional domain, and each region writes what belongs to it. High complexity: it requires clear ownership, consistency and routing rules.

High availability across br-sp-1 and br-sp-2¶

Reducing latency solves performance, not availability. When the database is critical, InteSys distributes the solution across the two Brazilian regions, independent in power, cooling and carrier, and separated by a few milliseconds.

Primary in one region, synchronous standby in the other, a highly available pooler in both and controlled promotion on failure.

• Primary in br-sp-1, standby in br-sp-2 (or the reverse) — proximity allows synchronous commit, with zero RPO, something unfeasible on intercontinental links.
• Synchronous quorum (ANY 1 OF 2) so that losing one standby does not block writes.
• Highly available pooler in both regions, with a VIP and the same rule set, keeping a single endpoint for the application.
• Controlled failover — promotion with lag verification and fencing of the old primary, preventing split-brain.
• Archived WAL and backups in storage separate from both regions, with periodic restore tests.
• Reads take advantage of the standby: the secondary region serves queries while it follows the primary.

For the details of topology, failover and backup, see PostgreSQL High Availability.

Managed PostgreSQL on Kubernetes¶

For customers already running their applications on Kubernetes, we operate PostgreSQL inside the cluster, with a PostgreSQL operator handling the database lifecycle: declarative topology, automatic failover, separate read and write endpoints, anti-affinity across nodes and regions, and continuous WAL archiving outside the cluster. Details are in PostgreSQL High Availability.

Decision matrix¶

By scenario¶

What should not go to the replica¶

Monitoring replication lag is part of the solution: routing rules must react to lag and take the replica out of service when it falls behind.

Data sovereignty¶

Distributing the database across regions does not mean taking data out of Brazil. Both InteSys regions — br-sp-1 and br-sp-2 — are Brazilian, and a topology spread across the two keeps full data residency: primary, replicas, WAL archive and backups all stay in the country.

• Distribution inside Brazil by default — the architecture described on this page runs entirely on Brazilian territory, under the LGPD, with no cross-border transfer to document.
• A replica in another country is a compliance decision, not just a latency one — if the application serves users outside Brazil, a read replica in that region means personal data leaving the country. Legal basis, scope and retention are settled in the design, before replication is configured.
• Logical replication limits the scope — you can replicate only the tables that need to be in the other region and keep the sensitive ones in Brazil. That is the practical difference between the physical and logical replication described above.
• Encrypted volume snapshots — the managed cluster on Kubernetes keeps snapshots on an encrypted volume, stored in Brazil (default) or in another country when the requirement is geographic isolation of the backup. Details in PostgreSQL High Availability.
• Single jurisdiction when that is the requirement — Brazilian infrastructure, contract and operations, without exposure to foreign data-access legislation.

How InteSys deploys it¶

1. Diagnosis — RTT, jitter, packet loss, connection volume and transactional behaviour.
2. Observability — identifying the most frequent, the slowest and the most WAN-sensitive queries.
3. Pooler — PgBouncer in the application's region, with separate read and write endpoints.
4. Regionalizing reads — streaming standby or selective logical replication.
5. Caching — selecting the right data for Valkey/Redis and the invalidation strategy.
6. Consistency rules — critical reads on the primary, safe queries in the local region.
7. High availability — distribution across br-sp-1 and br-sp-2, with synchronous quorum and WAL archived outside both regions.
8. Architectural evolution — regional API, Kubernetes or a distributed database, as needed.

Next Steps¶

• PostgreSQL High Availability — Topology, failover and backup inside the datacenter
• Multi-Region CockroachDB — Local writes in several regions, without a primary
• Multi-Region MySQL — The same architectures applied to MySQL
• InteSys Datacenters — Details of the br-sp-1 and br-sp-2 regions
• DevOps Overview — Full service catalogue