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

6 min read
PostgreSQL® Connection Pooling: Part 4 – PgBouncer vs. Pgpool-II

SHARE THIS ARTICLE

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!

How do the features stack up?

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

 

PgBouncer Pgpool-II
Resource consumption It uses only one process which makes it very lightweight. PgBouncer guarantees a small memory footprint, even when dealing with large datasets. Winner! If we require N parallel connections, this forks N child processes. By default, there are 32 child processes that are forked.
When are connections reused? PgBouncer defines one pool per user+database combination. This is shared between all clients, so a pooled connection is available to all clients. Winner! Pgpool-II defines one process per child process. We cannot control which child process a client connects to. A client benefits from a pooled connection only if it connects to a child which has previously served a connection for this database+user combination.
Pooling modes PgBouncer supports three different modes: session (connection returned to pool when client disconnects), transaction (returned to pool when client commits or rollbacks) or statement (connection returned to pool after the execution of each statement). Winner! Pgpool-II supports only session pooling mode – efficacy of pooling is dependent on good behavior from clients.
High availability Not supported. PostgreSQL high availability is supported through Pgpool-II in-built watcher processes. Winner!
Load balancing Not supported – PgBouncer recommends use of HAProxy for high availability and load balancing. Supports automatic load balancing – is even intelligent enough to redirect read requests to standbys, and writes to masters. Winner!
Multi-cluster support One PgBouncer instance can front several PostgreSQL clusters (one-node or replica-sets). This can reduce the cost for middleware when using multiple PostgreSQL clusters. Winner! (Note – this advantage is only for specific scenarios) Pgpool-II does not have multi-cluster support.
Connection control PgBouncer allows limiting connections per-pool, per-database, per-user or per-client. Winner! Pgpool-II allows limiting the overall number of connections only.
Connection queue PgBouncer supports queuing at the application level (i.e. PgBouncer maintains the queue). Winner! Pgpool-II supports queuing at kernel level – this can cause pg_bench on CentOS 6 to freeze.
Authentication Pass-through authentication is supported through PgBouncer. Winner! Pgpool-II does not support pass-through authentication – users and their md5 encrypted passwords must be listed in a file and manually updated every time a user updates their password.Pgpool-II does support passwordless authentication through PAM or SSL-certificates. However, these must be set up outside the PostgreSQL system, while PgBouncer can offload this to the PostgreSQL server.
Administration PgBouncer provides a virtual database that reports various useful statistics. Pgpool-II provides a detailed administration interface, including a GUI. Winner!
Host-based authentication Supported. Tied! Supported. Tied!
SSL support Full support. Tied! Full support. Tied!
Logical replication Not supported through PgBouncer. Tied! Supported through Pgpool-II, but this is done by sending the write queries to all nodes, and is not generally recommended. Tied!
License ISC – very permissive, basically allows all usage. Tied! Custom license – equally permissive. Tied!

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!

Using PgBouncer with Pgpool-II - Connection Pooling Diagram

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:

Number of clients Without pooling PgBouncer Pgpool-II (on box) Pgpool-II (off box)
10 16.96 26.86 15.52 18.22
20 16.97 27.19 15.67 18.28
40 16.73 26.77 15.33 18.3
80 16.75 26.64 15.53 18.13
100 16.51 26.73 15.66 18.45
200 Connections aborted. 26.93 Connections aborted when max-children > 200, pgbench hangs at max-children value if <= 100. Connections aborted when max-children > 200, pgbench hangs at max-children value if <= 100.

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:

Number of clients PgBouncer Pgpool-II (on box) Pgpool-II (off box)
10 58.37% -8.49% 7.43%
20 60.22% -7.66% 7.72%
40 60.01% -8.37% 9.38%
80 59.04% -7.28% 8.24%
100 61.90% -5.15% 11.75%

* 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!

For more information, please visit www.scalegrid.io. Connect with ScaleGrid on LinkedIn, X, Facebook, and YouTube.
Table of Contents

Stay Ahead with ScaleGrid Insights

Dive into the world of database management with our monthly newsletter. Get expert tips, in-depth articles, and the latest news, directly to your inbox.

Related Posts

pitr mysql

Master MySQL Point in Time Recovery

Data loss or corruption can be daunting. With MySQL point-in-time recovery, you can restore your database to the moment before...

Setting Up MongoDB SSL Encryption

In a world where data security is essential, enabling MongoDB SSL is critical in fortifying your database. This guide walks...

distributed storage system

What is a Distributed Storage System

A distributed storage system is foundational in today’s data-driven landscape, ensuring data spread over multiple servers is reliable, accessible, and...

NEWS

Add Headline Here