Lesson 9 of 14

Connection Routing for HA: VIPs, Pooler, and Read Scaling

Applies to PostgreSQL 13–17 Last reviewed May 2026 Grounded in source

The one thing to understand first

Replication and automated failover handle the database side of high availability, but they are useless if clients keep connecting to a dead or demoted node. Connection routing is how applications always reach the current primary for writes (and optionally a standby for reads), and how that target switches atomically during failover. Getting this layer wrong reintroduces the split-brain and downtime that the cluster machinery worked to prevent.

The routing layer must derive “who is primary” from the same source of truth as failover — never an independent guess. A VIP, HAProxy, or pooler that picks the primary on its own can point clients at the wrong node and undo every split-brain protection beneath it.

Approach 1: Virtual IP (VIP)

A floating virtual IP is assigned to whichever node is currently primary. The application always connects to the VIP; during failover the orchestration moves the VIP to the new primary. Clients need no awareness of which physical node is the leader.

This is a Pro lesson

Get every Learning Pathway and cookbook recipe — grounded in PostgreSQL source code, with diagnostics, fixes, and prevention for each topic.

Continue this lesson to learn:

  • Approach 2: HAProxy with health checks
  • Approach 3: pooler-based routing
  • Splitting reads to standbys
  • Layer 3 — Watch it happen on your own database
  • Layer 4 — The levers this hands you
  • Layer 5 — What an Oracle DBA should expect vs what they get
  • All 36 Learning Pathway lessons
  • 170+ cookbook recipes
  • Source-grounded diagnostics & fixes

Secure checkout Cancel anytime Source-grounded

Was this helpful?

← Back to 04 — Advanced: Replication & HA Architecture