Point-to-Point

Every complex replication topology starts from the same building block: one node talking to another node. Direct. No middlemen. No routing layers. Just A sends data to B.

This is point-to-point replication, and it is the topology you will encounter first in nearly every database setup. When you configure Postgres streaming replication for the first time, you get point-to-point. When you set up a MySQL replica, it connects directly to the primary. One source, one destination, one persistent connection.

It is also where most small-to-medium applications should stop. A single primary with a single replica handles more load than most people realize. Postgres on a db.r6g.xlarge (4 vCPUs, 32GB RAM) can handle 30,000-50,000 simple reads per second on a single replica. Unless your traffic significantly exceeds that, adding more complex topologies is premature optimization that buys you operational complexity without meaningful performance gains.

Airbnb started with a single primary and one replica. They did not introduce more complex topologies until their traffic genuinely demanded it. Basecamp has run on a single-primary, single-replica MySQL setup for years, serving millions of users. The simple path works longer than most teams expect.

The topology is as simple as it gets:

• Node A (primary) accepts all writes
• Node B (replica) receives changes from Node A and serves reads
• A single, persistent connection carries the replication stream
• If the connection drops, the replica reconnects and resumes from where it left off

There is no coordinator, no routing layer, no quorum. Just two nodes and a wire between them.

The replication can be any mode: async, sync, or semi-sync. The topology does not dictate the mode. Point-to-point just means "one source, one destination."

Failover in point-to-point is manual or automated by an external tool:

1. Primary dies
2. Something detects the failure (monitoring, health check, Patroni, pg_auto_failover)
3. Replica is promoted to primary
4. Application connection strings are updated to point to the new primary
5. When the old primary recovers, it is rebuilt as a replica of the new primary

The simplicity is the feature. There is one replication stream to monitor, one connection to troubleshoot, one replica to promote. When things go wrong at 3 AM, simple is your friend.

Connection management in point-to-point is also trivial. Your application needs two connection strings: one for the primary (reads + writes), one for the replica (reads only). If you are using a connection pooler like PgBouncer, you set up two pools. Compare this to a star topology where you need a load balancer across multiple replicas, health checks for each, and routing logic to handle failed replicas.