Request for Feedback on PostgreSQL HA + Load Balancing Architecture

Is this architecture considered a best practice within the PostgreSQL
community?

I would say Patroni is probably "best practice", but there are other people
out there happy with, and expert with, repmgr as well.

Are there any potential bottlenecks or failure points I should be aware of?

How is pgbouncer supposed to know which db to go to?I would think since
HAProxy has some way to tell, that pgbouncer should go on other side of
haproxy (between the app and haproxy)

Would you recommend any improvements or alternative tools for achieving

better reliability and performance?

Seems you need a witness server or some sort. Your HA system should have a
few main goals:

* Immediately fail over to a replica should the primary go down
* Reroute the application traffic
* Rebuild the old primary as a replica
* Never, ever allow there to be more than one primary server

Secondary goals:
* make the non-Postgres things redundant (as with keepalived and haproxy)
* provide read/write traffic routing (as you kind of have here)
* some sort of backup system (don't see any here)

Your design will also depend on how bulletproof you want your HA system to
be, and how much data your application is allowed to lose.

Cheers,
Greg

--
Crunchy Data - https://www.crunchydata.com
Enterprise Postgres Software Products & Tech Support

On 6/18/25 18:12, vijay patil wrote:

Hi Team,

I am planning to implement a PostgreSQL High Availability (HA) and
Load Balancing setup and would greatly appreciate your feedback on the
architecture we've designed (see attached diagram).

image.png

*Overview of the Setup:*

*

Two PostgreSQL nodes (VM1 and VM2) configured with:

o

Asynchronous replication from the Primary DB (on VM1) to the
Standby DB (on VM2) using |repmgr|

o

HAProxy for failover management:

+

HAProxy 1 (active) on VM1

+

HAProxy 2 (passive) on VM2 with Keepalive for heartbeat
and failover detection

o

PgBouncer on both nodes for connection pooling

*

A Virtual IP (VIP) managed by HAProxy for routing traffic from the
application

*

Read/Write operations go to the Primary DB, and Read-Only queries
can be served from either node

*Objectives:*

*

Ensure high availability with automatic failover

*

Enable basic load balancing for read-only queries

*

Maintain connection pooling and routing efficiency

*Request for Feedback:*

*

Is this architecture considered a best practice within the
PostgreSQL community?

*

Are there any potential bottlenecks or failure points I should be
aware of?

*

Would you recommend any improvements or alternative tools for
achieving better reliability and performance?

Personally I will test long run via app -> pgbouncer -> pgpool-ii in
order to combine :

* Query Routing (read/write automatic split)

* Load Balancing

* High Availability

* Query caching

Have you consider pgpool-ii ?  I know most support / service companies
push for patroni, and manually separating read / write traffic from
within the app, but I still find pgpool's query routing very nice.

On Wed, 23 Jul 2025 12:13:26 +0100
Achilleas Mantzios <a.mantzios@cloud.gatewaynet.com> wrote:
…

Have you consider pgpool-ii ?  I know most support / service companies
push for patroni, and manually separating read / write traffic from
within the app,

Indeed

but I still find pgpool's query routing very nice.

Using Pgpool for HA is a no go in my opinion. Pgpool HA requires the
DBA/sysadmin to deal alone with the real high availability challenges. Pgpool
doesn't handle the HA complexity itself, it stays quite "naive". It requires the
sysadmin/DBA to mess with the complexity to keep the cluster safe from
corruption. In other word, implement the HA safety stack in bash yourself. This
is partly true for repmgr as well last time I checked.

Don't implement Patroni or Pacemaker yourself in a collection of "action
scripts" triggered by a naive HA stack. Some people tried, some clusters has
been corrupted.

Pgpool for routing and/or pooling is an acceptable solution. Of course, it comes
with its drawbacks and some inefficiences, that's why most support/service
companies avoid it when possible. But depending on the context, it could be OK.

Regards,