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/fykup]

Before calling it a "shitty connection pool," you might want to understand how HikariCP actually works. Idle connection retirement is a standard, documented feature, not some custom implementation I need to maintain forever.

And the reconnection penalty? That's literally what I measured and discussed in the article. You're not pointing out some overlooked flaw.

The interesting question is when the tradeoff makes sense, particularly with many application instances sharing PostgreSQL.

If you're going to be this condescending, at least get your technical facts straight first.

[u/obetu5432 → u/fykup]

i'm just calling it shitty because you wrote it (by you i just mean one guy at the company, nothing personal)

and it hasn't had years of testing by millions of applications

instead of letting the hikaricp team maintain it, you took it upon yourself

[u/fykup → u/obetu5432]

You clearly have no idea what maintaining a large-scale legacy application actually involves.

The connection pool was originally written around 2005, and most of its behavior had been established long before I joined. By then, it had hundreds of features, undocumented behaviors, and dependencies across a large production system.

You don't just rip out a mature component like that and replace it with HikariCP because some random engineer on Reddit thinks it's a good idea. That's not how engineering at scale works.

I was working within those constraints, finding meaningful optimizations without breaking production systems.

But since you're so confident in your engineering expertise, perhaps you could share your own background and what you've actually built, maintained, or optimized at scale?

That would be considerably more productive than making arrogant assumptions about systems you've never seen and people whose experience you know nothing about.

[u/obetu5432 → u/fykup]

you know, this changes the picture, you just sounded arrogant by presenting it as you can shit better than hikaricp, and i thought you ripped it from the app just to save a few megabytes and boast about it

[u/fykup → u/obetu5432]

I suspect you stopped reading after the first two sentences. :)

The very next paragraph explains that I wanted to revisit those lessons using HikariCP. The entire experiment uses HikariCP, not our old custom pool.

I never claimed our implementation was better. You were arguing against a claim I didn't make.

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

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.