DPTCloud
Back to articles
Technology Insight

Building a High-Availability Multi-Region PostgreSQL Architecture: Real-Time Sync Between Vietnam and Singapore

June 3, 2026

Introduction: The Necessity of Multi-Region Database Architecture

In today’s hyper-connected digital economy, modern enterprises cannot afford downtime or sluggish performance. As businesses expand across Southeast Asia, delivering a seamless user experience requires serving data as close to the user as possible. For applications catering to audiences in both Vietnam and international hubs like Singapore, relying on a single-region database deployment introduces significant vulnerabilities and latency bottlenecks.

A Multi-Region Database (DB) Architecture solves these challenges by distributing data assets across geographically distinct data centers. This technical blueprint focuses on achieving real-time PostgreSQL synchronization between Virtual Private Servers (VPS) located in Vietnam and Singapore. Implementing this architecture ensures high availability, robust disaster recovery (DR), and minimal cross-border latency for distributed user bases.

The Architectural Blueprint: Vietnam and Singapore Topology

Deploying infrastructure across Vietnam and Singapore represents a strategic choice for regional businesses. Vietnam offers proximity to a booming domestic market, while Singapore serves as a primary cloud routing hub for global traffic. However, bridging these two regions requires a deeply integrated networks and database layer.

Network Infrastructure and the Latency Challenge

Before diving into database configuration, network stability must be addressed. The round-trip time (RTT) between Ho Chi Minh City/Hanoi and Singapore typically ranges from 30ms to 60ms under normal conditions. However, underseas cable disruptions can cause latency spikes or packet loss. Therefore, securing a stable connection via a Virtual Private Network (VPN) mesh or a dedicated private line is paramount to secure real-time replication.

Primary vs. Replica Configuration

In this architecture, we establish a primary-replica relationship tailored to traffic patterns. Depending on where the bulk of write operations originate, one region acts as the primary source of truth:

  • Primary Node (Vietnam VPS): Handles active transactional writes ($I/O$) from domestic users.
  • Read-Replica Node (Singapore VPS): Receives real-time streaming data from Vietnam, serving read-intensive queries for international users.

Alternatively, a multi-primary (active-active) setup can be leveraged using advanced extensions, though it introduces complex conflict resolution matrixes.

Mechanisms for Real-Time PostgreSQL Synchronization

PostgreSQL offers multiple native and third-party mechanisms to synchronize data across geographical boundaries. Choosing the right method depends heavily on business metrics like Recovery Point Objective (RPO) and Recovery Time Objective (RTO).

1. Physical Streaming Replication (Asynchronous)

Physical replication operates at the byte level, copying Write-Ahead Logs (WAL) from the primary server to the replica. For multi-region deployments, asynchronous streaming replication is highly recommended.

Because synchronous replication requires an acknowledgment from the Singapore replica before a transaction is committed in Vietnam, the 40ms+ network latency would severely choke write throughput on the primary node. Asynchronous replication ensures high performance by decoupling write commits from cross-border network transmission.

2. Logical Replication

Unlike physical replication, logical replication streams data changes based on the database identity (SQL statements/tuples) rather than raw disk blocks. This offers incredible flexibility:

  • Allows replication between different major versions of PostgreSQL.
  • Enables selective replication (e.g., synchronizing only specific tables critical to regional users).
  • Supports bidirectional replication frameworks, making active-active setups feasible.

3. Third-Party Extensions (BDR and Pglogical)

For advanced enterprise needs requiring multi-master capabilities where both Vietnam and Singapore accept writes simultaneously, tools like 2ndQuadrant's Bi-Directional Replication (BDR) or pglogical are employed. These tools handle complex conflict detection and resolution policies automatically based on timestamps or pre-defined business rules.

Step-by-Step Implementation Guide

Let us walk through the foundational steps to configure asynchronous physical streaming replication from a Primary PostgreSQL instance in Vietnam to a Standby instance in Singapore.

Step 1: Preparing the Primary Server (Vietnam VPS)

First, alter the postgresql.conf file on the Vietnam server to allow replication connections and configure WAL streaming:

listen_addresses = '*'
wal_level = replica
max_wal_senders = 10
wal_keep_size = 4096MB
hot_standby = on

Next, grant access permissions to the Singapore standby IP address in the pg_hba.conf file:

# Allow replication connections from Singapore VPS IP
host replication replication_user 198.51.100.50/32 scram-sha-256

Restart the PostgreSQL service to apply changes.

Step 2: Securing the Data Stream

Data traversing the public internet between Vietnam and Singapore must be encrypted. It is critical to enforce SSL/TLS encryption within PostgreSQL or route traffic through a secure WireGuard or IPsec VPN tunnel between the two VPS instances.

Step 3: Initializing the Standby Server (Singapore VPS)

On the Singapore VPS, stop the local PostgreSQL service and remove the existing data directory. Then, utilize the pg_basebackup utility to pull a pristine copy of the primary database:

pg_basebackup -h vietnam_vps_ip -D /var/lib/postgresql/data -U replication_user -P -R -X stream

The -R flag automatically generates the necessary standby.signal file and populates connection parameters, instructing the Singapore instance to start up as a read-only replica.

Mitigating Multi-Region Complexities

Operating a distributed database infrastructure introduces specific challenges that engineering teams must systematically address.

Managing Network Partitioning (Split-Brain)

In a multi-region setup, a temporary network blackout might cause the Singapore node to assume the Vietnam node is offline. If Singapore promotes itself to primary while Vietnam is still running, both nodes will accept distinct writes, resulting in a catastrophic split-brain scenario. To mitigate this, implement a consensus-based cluster manager like Patroni using an external Etcd or Consul quorum layer to safely orchestrate failovers.

Optimizing High Latency and Connection Pooling

Since applications in Singapore reading from the local replica enjoy single-digit millisecond latency, any write operations they send back to the Vietnam primary will suffer from cross-region lag. Utilizing connection poolers like PgBouncer reduces connection overhead, while application-level routing should strictly separate read and write database connections.

Conclusion: Achieving True Resilience

Implementing a real-time PostgreSQL synchronization strategy between Vietnam and Singapore establishes a solid foundation for regional scale. By combining asynchronous streaming replication with robust network encryption and automated failover orchestration, enterprises safeguard their operations against localized infrastructure failures while drastically improving the application response times for distributed user bases. Investing in multi-region architecture is not merely a technical upgrade; it is a vital strategy for business continuity across Southeast Asia.