I have a django website where the application and database server are different. I need to install pgbouncer to enable database pooling, however, I'm confused about where to install it: web application server or database server?

Note that in this set up, there is exactly 1 application server and 1 database server.

  • To decide where pgBouncer can be installed, it depends on your resources and performance. Our company installed pgBouncer on a stand-alone server (same network with application and database server) because we don't want to share resources of applications & database server with pgBouncer. However, if you have only two servers. I think you should consider about resources usage on two servers before installing pgBouncer (you can do several load-tests when installed it on application server or database server).
    – Luan Huynh
    Oct 25, 2016 at 3:12
  • @LuanHuynh how much resources pgBouncer can possibly use? We have it on some DB hosts, and never realized it had a performance hit, but it's also possible we were looking at the wrong place. Oct 25, 2016 at 8:28
  • guys, my perspective on it has now gone on the opposite end of the spectrum. Can you quickly skim this answer: serverfault.com/a/759377/321109 It makes sense to me. What do you guys think? Oct 25, 2016 at 11:05
  • 1
    @dezso: In fact, in production environment (Google CLoud), we have two test cases related to installed pgBouncer. Case 1: it is installed same DB host and case 2: it is installed in a standalone server. Then we do some load-tests over 10...3000 concurrent users. As a result, we choose installed pgBouncerin a standalone server to increase resources (RAM, CPU) for DB. However, in development env, we are still using pgBouncer in the same DB host, it works fine.
    – Luan Huynh
    Oct 26, 2016 at 2:23
  • @HassanBaig: I think you can installed pgBouncer in the same DB host, then do some load-test with your application. You can use jMeter.
    – Luan Huynh
    Oct 26, 2016 at 2:27

2 Answers 2


I would recommend first installing it on the database server. That way you can run top (or whatever) on that machine and have a one-stop-shop to see what is going on. Also, the dependencies are more likely to already be installed on the database server than they are on the application server.

If you then notice the database server is more heavily loaded than the app server, you can move it to the app server. But looking at the current loads (when you don't have connection pooling in place) to make that decision isn't going to be terribly useful, because they could change dramatically once you start pooling.


This is a official FAQ from pgbouncer web site:


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.