Using PGBouncer With CockroachDB Serverless

Given CockroachDB scales with vCPU, there's a hard limit to how many active connections we can support per vCPU before a serious problem arises. PGBouncer stretches the limits a bit making it a cost-effective option. In serverless architectures, there is no client-side connection pooling, and using middleware like PGBouncer can alleviate the problem of connection storms. Please see my previous articles on the topic for more details.


Previous Articles

  1. Using PGBouncer with CockroachDB
  2. Using PGBouncer with Cockroach Cloud Free Tier
  3. Exploring PGBouncer auth_type(s) with CockroachDB

Motivation

We've covered how to deploy PGBouncer with a self-hosted CockroachDB cluster. Today, I'm going to demonstrate how to run PGBouncer along with the Cockroach Cloud free-forever tier database. The overall concepts are identical, but we will highlight some of the major differences in deploying PGBouncer with a cloud product.

Postgres Connection Pooling and Proxies

One essential concept that every backend engineer should know is connection pooling. This technique can improve the performance of an application by reducing the number of open connections to a database. Another related term is "proxies," which help us implement connection pools.

In this article, we'll discuss connection pooling, implementing it in Postgres, and how proxies fit in. We'll do this while also examining some platform-specific considerations.

What Is Connection Pooling, and Why Should You Care?

As a developer, you may not have spent a lot of time thinking about database connections. A single database connection is not expensive, but as things scale up, problems can emerge. So let's (ahem) dive into the world of connection pooling, and take a look at how it can help us build more performant applications, especially when we're operating at scale.

A Typical Database Connection

Before we get into pooling, let's quickly review what happens when your application connects to the database to perform a database operation:

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

How Do the Features Stack Up?

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

PostgreSQL Connection Pooling: Part 1 – Pros and Cons

PostgreSQL Connection Pooling

A long time ago, in a galaxy far, far away, ‘threads’ were a programming novelty rarely used and seldom trusted. In that environment, the first PostgreSQL developers decided forking a process for each connection to the database is the safest choice. It would be a shame if your database crashed, after all.

You may also like:  PostgreSQL Connection Pooling With PgBouncer

Since then, a lot of water has flown under that bridge, but the PostgreSQL community has stuck by their original decision. It is difficult to fault their argument, as it’s absolutely true that: