0

We have 2 applications with ~10 instances of each. All these instances are connected to the same Postgres database.

The applications uses a client pool (some applicative ORM providing a connection pool locally)

We plan to install PgBouncer (one for all).

  • Is this a good plan for performances?
  • May I remove the application connection pool when I install PgBouncer?

2 Answers 2

0

It's definitely a good idea to use pooling at database side since you have multiple app instances. All 20 app instances can be effectively pooled at database reusing server(DB) connections. However I suggest

  1. Use load balancing mechanism(or tools like HAproxy) with two pgbouncer instances to avoid single point of failure. They must be peered together
  2. Use transaction pooling for effective pooling if your application not using session level features.

I think it's ok to have app layer pooling which keep connections active to pgbouncer.

1

You should not add pgbouncer unless it helps solve some problem. It is just another thing to configure, to break, and to the add latency. You haven't described any problem which pgbouncer is likely to solve.

The application is the most efficient place to do pooling. If it already exists you should not remove it just because you also use pgbouncer (which again, you should not do anyway). It would be different if the application pool were causing some problem, but you haven't described any.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.