PostgreSQL Connection Pooling: Part 4 – PgBouncer vs Pgpool-II

In our previous posts in this series, we spoke at length about using PgBouncer and Pgpool-II, the connection pool architecture and pros and cons of leveraging one for your PostgreSQL deployment. In our final post, we will put them head-to-head in a detailed feature comparison and compare the results of PgBouncer vs. Pgpool-II performance for your PostgreSQL hosting!

PostgreSQL Connection Pooling Series

• Part 1 - Pros & Cons
• Part 2 - PgBouncer
• Part 3 - Pgpool-II
• Part 4 - PgBouncer vs. Pgpool-II

How Do the Features Stack Up?

Let’s start by comparing PgBouncer vs. Pgpool-II features:

The bottom line - Pgpool-II is a great tool if you need load-balancing and high availability. Connection pooling is almost a bonus you get alongside. PgBouncer does only one thing, but does it really well. If the objective is to limit the number of connections and reduce resource consumption, PgBouncer wins hands down.

It is also perfectly fine to use both PgBouncer and Pgpool-II in a chain - you can have a PgBouncer to provide connection pooling, which talks to a Pgpool-II instance that provides high availability and load balancing. This gives you the best of both worlds!

Performance Testing

While PgBouncer may seem to be the better option in theory, theory can often be misleading. So, we pitted the two connection poolers head-to-head, using the standard pgbench tool, to see which one provides better transactions per second throughput through a benchmark test. For good measure, we ran the same tests without a connection pooler too.

Testing Conditions

All of the PostgreSQL benchmark tests were run under the following conditions:

1. Initialized pgbench using a scale factor of 100.
2. Disabled auto-vacuuming on the PostgreSQL instance to prevent interference.
3. No other workload was working at the time.
4. Used the default pgbench script to run the tests.
5. Used default settings for both PgBouncer and Pgpool-II, except max_children*. All PostgreSQL limits were also set to their defaults.
6. All tests ran as a single thread, on a single-CPU, 2-core machine, for a duration of 5 minutes.
7. Forced pgbench to create a new connection for each transaction using the -C option. This emulates modern web application workloads and is the whole reason to use a pooler!

We ran each iteration for 5 minutes to ensure any noise averaged out. Here is how the middleware was installed:

• For PgBouncer, we installed it on the same box as the PostgreSQL server(s). This is the configuration we use in our managed PostgreSQL clusters. Since PgBouncer is a very light-weight process, installing it on the box has no impact on overall performance.
• For Pgpool-II, we tested both when the Pgpool-II instance was installed on the same machine as PostgreSQL (on box column), and when it was installed on a different machine (off box column). As expected, the performance is much better when Pgpool-II is off the box as it doesn’t have to compete with the PostgreSQL server for resources.

Throughput Benchmark

Here are the transactions per second (TPS) results for each scenario across a range of number of clients:

Pgpool-II hangs when pg_bench is run with more clients than max_children. So, we increased the max_children to match the number of clients for each test run.

If we calculate the percentage increase in TPS when using a connection pooler, here’s what we get:

* Improvement algorithm = (with pooler - without)/without

Final Words

As you can see from the performance test results, a well-configured connection and well-suited connection pooler can drastically increase the transaction throughput, even with a fairly small number of clients. Connection poolers are especially useful for their queuing support - when the number of clients exceeds the max-clients supported by PostgreSQL server, PgBouncer is still able to maintain the transaction rate, whereas direct connections to PostgreSQL are aborted.

However, a badly configured connection pooler can actually reduce the performance as we saw with the Pgpool-II setup here. Part of the problem is, using Pgpool-II doubles the number of processes running on the same server - we must run Pgpool-II on a separate server to get a good performance. But even then, PgBouncer manages to provide better performance for these relatively small numbers of clients.

Also, note the test here was actually perfectly crafted for Pgpool-II - since when N > 32, the number of clients and number of children processes were the same, and hence, each reconnection was guaranteed to find a cached process. Even then, PgBouncer was the faster alternative.

So, our testing indicates PgBouncer is the far better choice for connection pooling. But, it's important to remember that while a connection pooler is absolutely mandatory for most realistic workloads, whether you gain more by using a client-side pool or middleware such as PgBouncer depends on your application. Patterns of data access would play a role, as would the latencies involved based on your architecture. We recommend testing your workload against both, and then decide on the best course of action - there is no better alternative to experimentation!