What Is Connection Pooling?

Your App and Its Database — A Quick Story

Every time someone opens your website or app, it often needs to ask a database for information. Think of a database like a library, and your app like someone who needs a book from that library. Each time your app asks a question, it has to open a new "connection" — like walking into the library, grabbing the book, and leaving.

Opening a new connection each time sounds simple, but it's actually slow. Setting up that connection takes time — usually between 50 and 500 milliseconds. That's not a big deal if it only happens once. But if your app handles hundreds of requests every minute, all those connection openings add up fast, and your app starts to feel sluggish.

Connection pooling fixes this. Instead of opening and closing a connection every single time, you keep a set of open connections ready to go — like a pool of library cards you can hand out instantly whenever someone needs one.

Speed and Stability for Real Apps

Without connection pooling, your app has to do a slow handshake with the database every time it needs something. That handshake eats up time and computer power. When lots of people use your app at once, the database can get overwhelmed — it can only handle so many open connections at the same time.

Connection pooling solves both problems. By keeping connections open and ready, your app responds faster. And by limiting how many connections sit in the pool, you stop your database from getting overloaded.

The Simple Steps Behind It

Here's what happens when an app uses connection pooling:

1. Startup: When your app first starts, it creates a pool of open database connections (say, 10 connections). These stay open and ready.
2. Request comes in: When a user asks your app for something, the app grabs an available connection from the pool instead of opening a brand-new one.
3. Use and return: The app does its database work with that connection, then sends the connection back to the pool — it doesn't close it. The connection is now free for the next request.
4. If the pool runs out: If every connection in the pool is in use and a new request comes in, the new request waits in line until one frees up. This prevents your database from being swamped.

The size of the pool matters. Too small, and requests have to wait. Too large, and you're wasting database resources. Most apps start with 5 to 20 connections and adjust from there.

Node.js With a Connection Pool

Here's a simple example using Node.js and the popular pg library. It sets up a pool of 5 connections and uses them to run queries:

// Import the pg library
const { Pool } = require('pg');

// Create a pool with 5 connections
const pool = new Pool({
  host: 'localhost',
  database: 'mydb',
  max: 5   // only 5 connections in the pool
});

// Use a connection from the pool — no opening needed!
pool.query('SELECT * FROM users WHERE id = $1', [42])
  .then(result => {
    console.log(result.rows);
  })
  .catch(err => {
    console.error('Query error:', err);
  });

// When shutting down, close the whole pool
pool.end();

Notice the max: 5 line — that controls the pool size. Every time you call pool.query(), it borrows a connection from the pool, runs the query, and returns the connection automatically. You never have to open or close a connection yourself.

Knowledge Check

Test what you learned with this quick quiz.