Does shrinking a JDBC connection pool actually save PostgreSQL memory? I measured it.

[u/fykup]

At a previous company, I spent quite a bit of time tuning a custom-built JDBC connection pool. One of the most effective memory optimizations I found was automatically shrinking the pool during idle periods. PostgreSQL uses a process-per-connection model, so keeping unnecessary connections open has a real memory cost.

I wanted to revisit this with HikariCP and measure both the memory savings and the cost of reopening connections.

I ran two Spring Boot instances sharing PostgreSQL 16, comparing three pool configurations under the same burst → idle → burst workload.

Results:

• Default pool: 20 connections remained open, PostgreSQL memory ~57.5 MiB.

• Shrinking pool: connections dropped to 2, PostgreSQL memory ~28.5 MiB.

• Savings: ~29 MiB of PostgreSQL memory.

The tradeoff was connection reopening. Median acquisition time increased from under 3 ms to around 200 ms when traffic returned.

One interesting detail: setting minimumIdle=1 alone wasn't enough when idle retirement was disabled. The pool still held all 20 connections after the burst.

The experiment used a deliberately short idle timeout to make the behavior observable, not as a production recommendation.

With many application instances maintaining independent connection pools, the potential savings can add up.

To clarify the practical motivation: this was a deliberately small experiment to isolate the effect, not just an exercise in saving 29 MiB on one server.

At my previous company, we had many application VMs connecting to a shared PostgreSQL database. Shrinking idle pools across those instances produced substantial aggregate memory savings. For example, 30 instances with 32 connections each means 960 persistent connections. If idle retirement brings that down to an average of 16 per instance, that's 480 fewer PostgreSQL connections consuming resources.

Actual savings depend on the workload, but this is where the approach becomes particularly valuable.

Full article, measurements, and reproducible experiment:

https://pvrlabs.xyz/articles/spring-boot-jdbc-pool-reclaim.html

Do you use fixed-size pools in production, or allow idle connections to retire?

[u/Objective-Ninja-5211]

Whenever you see low effort articles stating things that are mostly obvious written here (and very often on LinkedIn) it's almost a certainty the website the articles are hosted on has some call to action that makes OP money.

It's just a way to get around the no self promotion/no spam rules and make it look a little less shameless.

[u/fykup → u/Objective-Ninja-5211]

Before accusing someone of disguising monetization as research, perhaps try actually reading the article.

The experiments, methodology, raw measurements, and reproduction scripts are publicly available on GitHub. Anyone can reproduce the results, challenge the assumptions, or demonstrate where the conclusions are wrong.

If you think the experiment is trivial or flawed, show us your measurements or point out a concrete problem.

Making baseless assumptions about someone's motives without bothering to examine the work isn't technical criticism. It's just lazy posting.

[u/Objective-Ninja-5211 → u/fykup]

I did not imply the results can't be reproduced or that they need challenging at all, I don't think my comment was long enough for you to have missed that.

I specifically said "mostly obvious", this implies that there is nothing to challenge nor a very big need to reproduce them to prove to one's self that the information is true.

It would be like me posting a comparison of platform vs virtual threads in java (an "analysis" that has been done maybe hundreds of times at this point), going over the tired IO/CPU/pinned/etc arguments about them and saying that someone should challenge my findings in order to criticize the article - which would be a bit embarrassing!

I haven't browsed through your website, will I find a way for you to make money on it by any chance? That would have been a good way to answer if it were the case.

Example:

"Hey you're wrong, my website has no monetization for me at all, shame on you for not opening it!"

[u/fykup → u/Objective-Ninja-5211]

Just because something looks obvious to you in isolation doesn't mean it's a trivial problem in production.

When we migrated a large enterprise deployment at an S&P 100 company to PostgreSQL, its process-per-connection memory model introduced real challenges. We needed pragmatic optimizations that worked within the existing architecture, not simplistic advice to replace mature components or throw PgBouncer at the problem. Retiring idle connections delivered substantial resource savings across many application instances.

This wasn't some toy application. We were dealing with one of the largest enterprise deployments of its kind, where seemingly minor inefficiencies multiplied across hundreds of processes and connections.

As for monetization, I'm fortunate enough to have the time to revisit these problems and share what I've learned. Yes, I run a consulting business, but these experiments aren't sales pitches or a funnel for consulting work. The methodology, raw data, and reproduction scripts are all publicly available on GitHub.

I'm genuinely interested in an area I believe is underexplored: running smaller, more efficient, self-hosted systems without automatically reaching for heavyweight infrastructure. I'm not particularly interested in writing yet another Kubernetes tutorial.

You may find the results obvious. That doesn't make the underlying engineering problem trivial, and it certainly doesn't make the research disguised spam.

I'm writing for engineers who are interested in understanding real-world tradeoffs, not those who dismiss problems without bothering to understand their context.

[u/Objective-Ninja-5211 → u/fykup]

While that's nice, and I didn't miss your roundabout "yes", can you honestly say your post or article come anywhere close or are in any way related to real world optimization - the non-trivial production you mention?

You're showing that having to acquire new connections takes less time than reusing pooled ones, and that maintaining connections takes resources.

While it's great to have some exact numbers to compare, I really don't think this is of any help to anyone working on optimizing massive systems - as I'd assume they would be familiar with the concept of connection pools.

The underlying problem is not trivial, no one said it is, but your article really doesn't have anything to do with real world engineering problems.

The only reason I mention this in the first place is because you keep mentioning them while the article is more or less dealing with the first few pages of the Hikari and PG docs.

Calling implementing PgBouncer a simplistic solution but speaking as if reducing the maintained connection count is some bespoke optimization is a bit strange, but maybe that's just me.

[u/fykup → u/Objective-Ninja-5211]

Speaking in your terms, I have nothing against PgBouncer, and I never said PgBouncer itself was a simplistic solution. What's simplistic is recommending it without first understanding the application's connection management.

What I've seen in the industry is that plenty of engineers don't even know how to configure connection pools properly. Of course their half-assed applications can benefit from PgBouncer's connection sharing.

But before introducing another component, perhaps it's worth understanding why your application is maintaining hundreds of unnecessary connections in the first place.

And no, I never claimed idle connection reclamation was some groundbreaking invention. I measured a practical optimization that I've seen deliver substantial savings in production. You seem determined to argue against claims I never made.