I Thought 100 Requests Meant 100 Database Connections

Ayantik Sarkar

3 min read

·

Sep 6, 2026

--

Listen

Share

Press enter or click to view image in full size

I kept hearing about database connection pooling while learning backend development.

At first, it sounded like one of those backend terms that everyone knows except me.

So I decided to actually understand what was happening.

The confusion

Suppose my backend is connected to MongoDB.

A request comes in and needs some data:

Request
   ↓
Backend
   ↓
MongoDB

I initially thought that every request creates a new connection to MongoDB.

So if 100 requests come in:

100 requests
    ↓
100 database connections

That obviously doesn’t sound very efficient.

Then I learned about connection pooling.

So what is a connection pool?

Instead of creating a new connection every time, the backend maintains a pool of reusable database connections.

For example:

Backend

  Connection Pool
┌──────────────────┐
│ C1 C2 C3 C4 C5   │
│ C6 C7 C8 C9 C10  │
└────────┬─────────┘
         ↓
      MongoDB

If I configure:

maxPoolSize: 10

the pool can have up to 10 connections being used concurrently.

When a request needs MongoDB, it gets an available connection.

When the database operation finishes, the connection is returned to the pool.

It isn’t destroyed.

It can be reused by the next request.

Then I got confused again

Okay.

If there are 10 connections and suddenly 100 requests arrive, what happens?

I initially thought:

“So 10 requests will run and the other 90 will just wait until the timeout?”

That’s mostly the right idea, but there’s an important detail.

The other requests don’t necessarily wait until the timeout.

They wait for a connection to become available.

For example:

10 connections
10 requests using them

90 requests waiting

Then one request finishes:

Connection becomes free
        ↓
One waiting request gets it
        ↓
That request runs its MongoDB operation

So the pool is basically controlling how many database connections are being used at the same time.

The timeout is just the maximum amount of time a request may wait for a connection before failing.

But then came my bigger question

If this is how connection pooling works, what happens at the scale of something like Amazon?

They get millions of requests.

Surely they can’t just have a pool with a million connections.

And that’s when I understood something important.

Connection pooling isn’t what makes a system handle millions of requests.

The application itself is scaled horizontally.

Instead of having one backend server:

Users
  ↓
Backend
  ↓
MongoDB

you can have many backend servers:

                 Users
                   ↓
             Load Balancer
          ┌────────┼────────┐
          ↓        ↓        ↓
       Server 1 Server 2 Server 3
          ↓        ↓        ↓
       Pool      Pool      Pool
          └────────┼────────┘
                   ↓
                Database

Each backend server has its own connection pool.

So you might have:

Server 1 → pool of 50
Server 2 → pool of 50
Server 3 → pool of 50
...

Not:

1 million requests
       ↓
1 million database connections

That’s the part that finally made sense to me.

And large systems go even further

At really large scale, you don’t simply keep adding connections.

The database itself becomes a bottleneck.

That’s where other things come into play:

• Caching to avoid unnecessary database queries
• Indexes to make queries faster
• Replication to distribute reads and provide redundancy
• Sharding to distribute data across multiple database servers
• Horizontal scaling to add more backend servers
• Connection pooling to efficiently manage database connections

So connection pooling is just one piece of the scalability puzzle.

The simplest way I remember it

I think of database connections like checkout counters.

Imagine a supermarket with 10 counters and 100 customers.

You don’t build a new checkout counter for every customer.

You have 10 counters.

Customers use an available counter, finish, leave, and the next customer uses it.

That’s basically what a connection pool does.

The important thing I learned is:

Millions of requests don’t mean millions of database connections.

You scale the application and database architecture, while keeping a controlled number of reusable connections between them.

And honestly, once I understood that, “connection pooling” stopped sounding nearly as complicated as it did before.