What Is Database Pooling — and Why So Many People Get It Wrong

Fri Jun 06 2025

This issue is rampant in Node.js, Go, and Python — basically anywhere you're not using a meta-framework like Java Spring Boot or Python Django.

In contractor-heavy environments with no real code reviews, things like this slip through. And they quietly burn your system with way more resource usage than necessary.

Take this common anti-pattern:

const sql = require('mssql');

var pool = await sql.connect(config);
var query = "SELECT * FROM TABLE";
var result = await pool.request().query(query);

I’ve seen this copy-pasted into dozens of methods. One connect() call per API. What’s wrong with it?

❌ Why This Is a Problem

Every time you call an endpoint, the app reconnects to the database:

Network call → Authenticate → Allocate new connection → Run query → Return result

Now imagine:

Every API call does this
Dozens or hundreds of users hit the system
You’re running in a limited connection pool

Your database gets hammered not by queries, but by connection spam.

When the pool overflows, the DB has to:

Figure out which connections are idle
Kill those
Start new ones
Authenticate again
Maybe finally run your query

This is silent tech debt. And it scales like a time bomb.

✅ How It’s Done Right

Frameworks like Spring Boot have HikariCP under the hood — a high-performance connection pool you don’t even think about. You just inject DataSource and go.

In Node.js and other minimal stacks? You have to manage it yourself.
At minimum:

// db.js
const sql = require('mssql');
const poolPromise = sql.connect(config);
module.exports = poolPromise;

Then in your services:

// userService.js
const pool = await require('./db');
const result = await pool.request().query("SELECT * FROM Users");

One connection pool. Reused. As it should be.

🧨 TL;DR

Don’t sql.connect() on every API call.
Connect once on app startup.
Reuse that pool. Always.

Otherwise, you're not building a backend — you're building a denial-of-service engine.