alt.hn

8/12/2026 at 8:13:06 PM

Does anyone run Postgres without PgBouncer?

 https://brandur.org/fragments/postgres-without-pgbouncer

by abelanger

8/16/2026 at 2:15:32 PM

(I work on the postgres proxy layer at Neon)

PgBouncer is entirely optional and it's not always the right choice. If you have a classical app (non serverless) and you can maintain a connection pool from your app, then I recommend avoiding pgbouncer.

The benefits of pgbouncer mostly come from irregular client connections (too many, too much churn). If you don't have that problem, go direct to postgres.

I'm exploring replacing pgbouncer with an alternative (maybe home grown) at the moment. Mostly for multi-tenancy and HA reasons. Pgbouncer has been good for us, but it's limited in how we can deploy it in a multi-tenant environment.

by conradludgate

8/16/2026 at 3:42:34 PM

Also some people with use cases that shouldn't need PgBouncer end up thinking they do because something else is misconfigured. This was brought up in a parent of https://news.ycombinator.com/item?id=49019695; FastAPI recommends dep-injecting transactions into your HTTP handlers. Ties up all your connections and creates idle xact spam. There are valid reasons to use PgBouncer, this isn't one.

Even on serverless platforms like Heroku, I've been fine giving each worker a pool such that max_workers * pool_size < max_connections.

by frollogaston

8/16/2026 at 6:59:23 PM

That’s ok if the number of workers is bounded and small. But if you’re operating on the order of hundreds to thousands of workers, maybe not so much.

by catlifeonmars

8/17/2026 at 1:17:22 AM

Can you add more on why Pgbouncer is limited in a multi-tenant environment?

by 00117

8/17/2026 at 4:58:08 PM

pgbouncer runs as a single threaded service, so it ends up getting bottlenecked by some heavy clients on typical server CPUs with low clock speeds.

Sharding/peering pgbouncer works, but it's not perfect.

More significantly for us is that Neon has millions of databases in each region, and thousands get created/destroyed every hour. Managing the pgbouncer config and shared connection pools will be extremely tricky to balance. We have a bunch of logic for this in the proxy I maintain, but not in pgbouncer.

The main intent is to incorporate a pooler directly into our existing proxy service to avoid needing double proxy services. We just need to find the right pooler implementation (and one that works in async Rust)

by conradludgate

8/16/2026 at 3:29:42 PM

And the only comment in this whole thread, who argues for a similar architectural alternative...is the ONLY one in the whole thread down voted. HN continue to excel in technical chops...

https://news.ycombinator.com/item?id=49319988

https://news.ycombinator.com/item?id=49320460

by root-parent

8/16/2026 at 6:23:50 PM

Unless I'm missing something, your linked comments seem to be responding only to the title of the article, without addressing any of the actual points being made in the body of the article?

by evanelias

8/16/2026 at 11:44:25 PM

Lol, linking your own comments is pretty weird

by BowBun

8/16/2026 at 2:26:50 PM

This question will get more interesting responses if it was qualified as:

"Does anyone run Postgres without PgBouncer for non-trivial workloads?"

Because, as we can see from the comments so far, lots of people are going to say you don't need it for your blog that gets 10 hits a month.

I've personally never heard of anyone not using PGbouncer, or some connection pooling proxy, for reasonably concurrent workloads. PG's process-per-connection architecture almost requires it. Otherwise even a small connection storm will wreak havoc on your server.

by petcat

8/16/2026 at 5:31:41 PM

Not all non-trivial workloads are web-scale. There are plenty of on-premise applications out there that have at most hundreds or thousands of concurrent users, and the connections come from a bunch of fat spring boot servers that handle most of the pooling by themselves.

by mrighele

8/16/2026 at 10:50:59 PM

Atlassian apps.

by Geezus_42

8/16/2026 at 3:55:15 PM

Yes, I've done a variety of typical, nontrivial workloads on Postgres for about a decade and have never used PgBouncer. Though I can imagine use cases where it'd make sense.

by frollogaston

8/17/2026 at 1:23:06 AM

I believe it would add color to the discussion if you enumerated a few of the details of those workloads.

by benji-york

8/17/2026 at 3:56:31 PM

1. Typical backend with a DB, serving either a web/mobile app or other services within a company. Each job had a pool, so there's a steady number of connections to the DB that didn't exceed what it can support, with some headroom for monitoring, cronjobs, and emergency access. Xacts were usually short. Was able to handle high QPS, and when it hit the limits, it was something on the DB rather than backend CPU starvation, so adding more backends and thus connections wouldn't have helped. Even though some of these were on Heroku which has a rather low DB connection limit.

2. Data pipeline that used Postgres queries as sort of a map-reduce. Not ideal but I think not that uncommon. Each machine had a local DB with mostly temp tables, plus there were some shared DBs. Each running stage in the pipeline needed one connection per CPU core because queries were sharded that way to utilize all cores.

3. Another data pipeline that used batch workers that did their bookkeeping in a DB. This was infrequent enough access that I had each one opening a connection right before using it then closing it after. PgBouncer would make sense there, but we were fine even if every worker opened a connection at the same time. That's partially because many of those workers were GPU instances, so there weren't terribly many of them.

I'm actually wondering who is in situation #1 and needs PgBouncer, and why exactly. The scenario I have in my head is you're doing heavy CPU work directly in your web workers, and thus you need more workers than you have DB connections available, which seems like it's more monolithic than it should be.

by frollogaston

8/16/2026 at 3:20:20 PM

Good question.

PGBouncer isn't as useful if you have seriously long-running transactions. It can’t do much of anything with those. Sure, you can give it a pool of 1000 and your Postgres instance a pool of 100, but you’re just moving who is going to say, “sorry, the database can’t handle your request right now.”

It’s not a silver bullet.

If you have more connections than Postgres can handle on the hardware it’s on, but with a bit of buffer it’ll be able to burn them down: great.

If you have long-held connections with many transactions that PGBouncer can interleave: great.

If you have connections whose transactions are longer than a reasonable timeout, well, your optimization princess is in another castle.

by tyre

8/16/2026 at 7:56:00 PM

>I've personally never heard of anyone not using PGbouncer, or some connection pooling proxy,

There is plenty of space for large systems which need a database but don't have a large number of clients.

It's a matter of the scale of your data vs. the scale of your readers and writers.

by colechristensen

8/17/2026 at 4:49:00 PM

If you do have a large number of clients, PgBouncer only means you have a single shared pool of connections rather than each replica having its own smaller pool. You already have a load-balancer for the web clients, so the latter is maybe fine. Of course this doesn't work if you have more replicas than available DB connections.

by frollogaston

8/16/2026 at 8:06:35 PM

Yes. The internal services should be doing stuff in bulk and not require too much parallelism. That leaves you with the number of concurrent users, which in b2b apps can be quite low.

by giveaccountpls

8/16/2026 at 8:01:06 PM

Here, a single database, 300 transactions/s, between 10 - 20 TB dataset size. HA managed by VIP (keepalived).

by krab

8/16/2026 at 3:13:54 PM

I feel like there are a lot of use cases where I’d opt for SQLite and a lot of use cases where I’d opt for Postgres + PgBouncer. I’m curious what kinds of features push towards using Postgres alone over SQLite.

by ummonk

8/16/2026 at 3:24:24 PM

All of my personal apps use Postgres because:

- types are lovely. We love types. SQLite’s default of non-strict typing is, to me, bananas.

- SELECT DISTINCT ON is my ride-or-die

- most importantly, I’m very comfortable in Postgres and the setup cost is basically zero (like SQLite) because Claude does it.

by tyre

8/16/2026 at 6:00:56 PM

The setup cost is basically zero anyway. Add apt repo, apt-get install the correct version. Easy to run different versions at the same time too. Upgrading is annoying.

by panzi

8/16/2026 at 5:21:34 PM

Concurrency, data types, scalability, centralization, or replication push for Postgres. The push against PgBouncer is that you don't need it, unless you do. If you have an app-level connection pool, you probably don't need PgBouncer.

by pocksuppet

8/17/2026 at 3:39:33 AM

I can go either way on this topic, however for the sake of engineering lets invert this problem a little bit and take it upstream. When your entire system is thread based (unique thread assigned to a given request) then even with pgBouncer you end up standing in line to wait for the connection. Most IO heavy application servers now just have the threads waiting for DB connections cause you just scaled (increased number of instances) the application servers for the load. This thread waiting could have been done on web server level as well, allowing one to manage DB connections in application server instead of adding pgBouncer.

tldr; a lot of times pgBouncer is just a duct taped solution to upstream problem. You can easily have web scale (?) application without pgBouncer if you application logic allows it and you pick a applicable design choice.

by sandeepkd

8/19/2026 at 11:50:41 AM

yes, if you control the clients and do client-side pooling.

by fuy

8/16/2026 at 4:36:25 PM

The main Question is: why do you allow clients to connect to your database server, it should be limited to a server which could actually serve the data in a format the client can just render without any logic client side.

by Asmod4n

8/16/2026 at 3:26:45 PM

Article title is pure click-bait. PgBouncer adds complexity. If you need it, you need it. If you don't need it, then you added complexity for nothing.

> since neither IBM nor Oracle is a service that any self-respecting person not part of an enterprise sales cycle would actually use

Author needs a serious ego check. There are legitimate engineering reasons to pick IBM Cloud (like if you need to support Z mainframes, which you will sometimes need if you sell to those enterprise folk) as well as Oracle Cloud (they built datacenters in cities that are not served by other cloud providers and can thus offer the lowest latency). These reasons may not be common, but they're certainly legitimate.

by solatic

8/16/2026 at 4:18:51 PM

It's an ironic claim because the Oracle cloud has great support for the Oracle Database, which doesn't require "bouncers" or equivalent. Its support for server-side connection pooling, client side load balancing (SCAN) and horizontal scaling means it offers exactly what the author wants - a single URL that just magically works and scales to any amount of work or connections cheaply.

https://docs.oracle.com/en/database/oracle/oracle-database/2...

Yet he says simultaneously that Postgres hasn't improved in a decade, but also no self-respecting person would use a database that fixes all the problems he identified. Right!

Disclosure: work part time in the Oracle DB group. Things I say here are unvetted, personal opinions.

by mike_hearn

8/16/2026 at 6:26:01 PM

Oracle licensing audits scare off plenty of folks.

At a small SaaS we were put off by the difficulty getting OracleDB's dev edition installed and working at all. While MySQL (then independent) and Pg were bare bones in comparison, they were very quick to get started, covered what was needed, and no risk of price spikes or time consuming audits. When pain points were encountered with MySQL and Pg there were plenty of flexible options to add into the mix.

Later I saw a competitor being crushed by licensing for Informix when they didn't need more than ~10% of its features.

by paulryanrogers

8/17/2026 at 7:25:59 AM

I believe you, but these days it's just a container launch to do local dev, no different to postgres. In the cloud there are no license audits. Those are only for on-prem setups where licensing servers aren't acceptable.

If you don't need the features of a commercial database then they're not worth the cost indeed.

by mike_hearn

8/16/2026 at 5:00:54 PM

Slightly off topic, but a friend of mine worked on Microsoft SQL Server a ~decade ago, and I recall all sorts of conversations on types of optimizations they were doing that sounded truly magical compared to other databases at the time. There was a meaningful frustration on the team that their features weren't getting as much hype as the databases du jour.

I think it's very relevant to consider that "enterprise" adjacent databases may not support the licensing you need at scale - but that doesn't mean they don't have great engineering and research teams that are solving really difficult challenges, and those challenges may be highly relevant to your workflows. Go into things with an open mind, if not an open wallet!

by btown

8/16/2026 at 6:05:24 PM

Yeah, that's a common sentiment. I regularly see people describe features commercial RDBMS' have shipped for years as if they were unmapped frontiers in computer science. Awareness of their capabilities is very low; I was once there too and remember being taken by surprise when I realized how far ahead of open source they truly are.

IMO startups can get edge by exploiting this information asymmetry. Spending a bit more to solve all your DB problems and buy productivity is a no brainer as they have VC funding but not enough time. A single bad DB outage can be the difference between beating a competitor or losing to them. Ditto for slowly shipping a feature because your senior dev is trying to implement their own message queue engine or other random thing that comes out of the box in other RDBMS engines.

The costs depend what you compare it to. People tend to overestimate it. Cost multipler in Azure is very roughly about 4x, it seems (caveat: am not a cloud pricing expert, comparisons may vary wildly). That doesn't include the cost of bouncers and other hacks that increase the Postgres cost, so it's artificially generous to PG.

If you want better features on the Postgres side then you might look at AlloyDB in Google Cloud which is only 2x cheaper on compute but where storage is actually ~3x more expensive!

The extra money buys you a lot. Not only far more features but you can provision a smaller database because the Oracle DB burst scales in response to load. You are only charged for the extra you use so you can provision for normal load without padding extra for emergencies or peaks. It's a genuine cluster that scales up writes more or less indefinitely without sharding if you design your schema right, that's synchronous multi-write master scaling too so its simple for apps. You don't face OpenAI style problems where the single Postgres master reaches its limits and the whole thing breaks requiring app redesigns. And you aren't just paying for an idle replica: all the capacity you buy can be used for queries. It also uses more efficient algorithms e.g. better MVCC with no autovacuuming problems. And a gazillion other things.

So I think you can easily argue that value delivered is much greater than 2x-4x. The capability gap is much larger than 4x. Especially if you're the sort of startup where a bored dev might start citing Postgres' limitations to justify inventing their own DB infra, or where you hit its scaling limits and have to rearchitect - if that happens you'll never recover the cost difference, Oracle will always be cheaper.

This happens because clouds don't charge databases at licensing+labor value+margin, prices are set at what the market will bear.

by mike_hearn

8/17/2026 at 12:31:04 AM

I truly wish that Oracle wasn't so aggressively hostile WRT licensing enforcement, because its DB capabilities are insane. I've never operated it, but all the docs I've read are legitimately impressive.

I support getting paid for your product, but charging per-core/thread is frankly absurd, and charging for cores that aren't even being used by the product is beyond the pale.

by sgarland

8/17/2026 at 7:31:49 AM

Licensing in the cloud is like all cloud services, cost scales with use. I think you're talking about on prem usage which isn't relevant to most new users.

by mike_hearn

8/17/2026 at 4:40:32 PM

Does this apply if using cloud environments other than Oracle's own though? (Which is a far cry from on-prem, and relevant to perhaps a vast majority of businesses.)

Documents like https://www.oracle.com/a/ocom/docs/cloud-licensing-070579.pd... suggest that licensing for these environments is complicated at best, with the onus of reporting lying on the customer not the cloud provider.

by btown

8/16/2026 at 8:35:28 PM

Oracle DB may be excellent, but there is no chance I'd ever ever ever do business with Oracle due to their aggressive business practices.

by tensor

8/16/2026 at 4:46:00 PM

I do not think it is a mystery why people favor Postgres over OracleDB, is it?

by moooo99

8/16/2026 at 6:06:19 PM

Depends what you mean by people. Outside of the startup space you'll find commercial RDBMS everywhere, especially OracleDB. Not many are running banks or hospitals on Postgres.

by mike_hearn

8/17/2026 at 8:50:42 AM

> Not many are running banks or hospitals on Postgres.

Certainly not. But the key here is that not many are running banks or hospitals in the first place.

I work at a big company, we run on SAP as the big commercial DBMS, but also have some oracle instances. By number by far the most widespread commercial RDBMS seems to be SQL Server

by moooo99

8/16/2026 at 11:33:17 PM

I use PG without PG Bouncer for non trivial traffic levels using the same type of application level connection pooling I’ve used for years with every other database.

Bouncer is a nice option, but definitely not required.

by brightball

8/16/2026 at 2:25:22 PM

Python: absolutely necessary due to the amount of processes and various deployments to run an application once it grows.

Java: never felt the need even on quite big apps. As it's much easier to share a connection pool locally, it's not as many single connections across the whole app.

by matsemann

8/16/2026 at 3:10:57 PM

Your high level buckets are languages but the constraints you list are usage patterns.

You can build applications in any language that have many short-lived transactions in single connections or a few huge, blocking one, or anything in between.

The former case is a good one for PGBouncer (it can interleave transactions) and the latter isn’t (it can’t do much about your three minute long BEGIN…COMMIT). Neither has to do with the language.

by tyre

8/16/2026 at 3:22:12 PM

They addressed this though? I suspect you are unfamiliar with the GIL in python. The reason for a language distinction is because, as OP says: "As it's much easier to share a connection pool locally".

This may change vaguely soon, but right now you typically scale python apps by starting multiple python processes, while for Java you can just add threads. Python processes can't share a thread pool among all of them, while Java can.

by atomicnumber3

8/16/2026 at 3:39:41 PM

> I suspect you are unfamiliar with the GIL in python.

Sadly, I’m deeply familiar. What made Evan Phoenix’s Rubinius work so exciting in ~2012 was getting rid of the GIL and seeing what was “fixed” by parallelism and what was not.

You make a good point. I didn’t read the parent comment that way but you’re right about how you scale python with the GIL vs JVM.

by tyre

8/16/2026 at 9:30:29 PM

You've misunderstood the GIL and Python threads.

For I/O, you can add threads and share the same connection object. Like any other languages, you are responsible for making it thread-safe.

There's also async. Many Python web apps spawn a thread per worker in your web server, not processes. Look into ASGI vs WSGI.

by ketozhang

8/16/2026 at 5:23:04 PM

Languages have affordances. At the extreme ends are PHP, and Java or Go. PHP runs a separate logical process on every request which can't share resources with any other request. Almost everyone using Go is writing a long-running server process because that's how the libraries are designed. Almost everyone using Java is writing a long-running process or a module for one, because Java startup times are obscene. Java also has a very convenient synchronization primitive.

by pocksuppet

8/17/2026 at 4:31:33 AM

> PHP runs a separate logical process on every request which can't share resources with any other request.

PHP allows persistent connections to postgres that will be reused by subsequent requests. But of course the connection isn't shared by concurrent requests (unless you use Swoole), so it doesn't solve the process-per-connection on postgres' side, it merely saves some overhead.

by tredre3

8/16/2026 at 6:25:05 PM

Multi-threaded processes are used because that's the most efficient model, hardware wise. Tasks can maximally share resources. It's not to do with library design or startup time.

by mike_hearn

8/16/2026 at 9:45:44 PM

The hardware doesn't know anything about processes. The most efficient model, hardware-wise, is to disable virtual memory and never do a context switch, but we don't see anyone programming like that, except for the crazy SDN folks who are doing software packet forwarding at hundred-gigabit rates.

by pocksuppet

8/17/2026 at 7:23:05 AM

Well, a server running a single process is fairly close to that. Switching to kernel mode doesn't require a full context switch and nor does switching between threads.

by mike_hearn

8/16/2026 at 9:23:47 PM

It's more so horizontal vs vertical scaling rather than languages.

You aren't running large scale xact/s on a single node.

by ketozhang

8/16/2026 at 3:39:09 PM

I see many comments comparing PgBouncer with application connection poolers without addressing the conceptual difference between them. Here it is:

1. Most application connection poolers follow a first-in-first-out (FIFO) algorithm, which is simple enough to implement and is enough to make sure the application always has a connection available to connect to the database. It optimizes low latency, and works great from the point of view from the application. The problem is that it has few mechanisms to remove redundant connections, since the application is constantly keeping them all "warm".

2. PgBouncer and very few external poolers follow the inverse idea – last-in-first-out (LIFO), and they optimize for reducing the number of connections that reach Postgres, thus improving its throughput. The idea might seem crazy at first – the last connection used is the first one to be picked up again – but this algorithm automatically removes excess connections, which will get cold and get closed.

When starting a new application, option (1) is enough, but as it scales up enough, at some time it is recommended to use (2), since having hundreds of open connections to Postgres is bad for performance if you can use PgBouncer or similar to cut it by 90%. Postgres' process-per-connection design works much better when there are fewer connections reaching it.

by giovannibonetti

8/16/2026 at 3:12:08 PM

If you have a connection pooler in your application, and the DB is only used for this application, you don't need an external pool like PgBouncer. That is probably a pretty common scenario, and typical web frameworks include a connection pool anyway.

An additional complication is that more aggressive pooling methods have side effects that you must know and prevent in your application. They're not safe to use out of the box.

The need for a connection pool is a side effect of the heavy process-based PostgreSQL connections. And I would suspect that this will change at some point in the not so near future, so that users don't have to think about this part this much.

by fabian2k

8/16/2026 at 4:28:42 PM

It's a little more nuanced than that. At my company we run Kubernetes workloads where we have 20-30 or sometimes more pods connecting to a single Postgres instance, each pod handling hundreds of concurrent requests. If each pod hangs on to pooled connections for more than a few seconds, then you end up with quite a few Postgres processes and a lot of memory usage and process churn; we mitigate that by having a relatively short TTL on the pool, so idle ones get reaped relatively quickly. But any idle connection not used by a pod can't be used by a different pod. A connection pooler lets all the pods share more connections to Postgres, reducing in less wastage.

by atombender

8/16/2026 at 5:04:16 PM

SRE here, that's a ton of pods and sounds like it's language or architecture if you are serving up so few requests per pod.

We have Kubernetes here too for Java monoliths and we have 8 Pods serving more than that. Since Java has connection pooling, the overhead has never been enough to justify overhead of Pgbouncer for this Java app.

by stackskipton

8/16/2026 at 5:52:00 PM

Our workloads are served by Go processes, so quite lean. But the workloads are relatively CPU-bound and memory-hungry.

by atombender

8/16/2026 at 3:57:09 PM

> If you have a connection pooler in your application, and the DB is only used for this application, you don't need an external pool like PgBouncer.

But this is only true if you have no more than a few running instances of your application. So it feels like the cases where you must have Postgres (over an alternative like SQLite) but can't justify PgBouncer are very narrow.

by aobdev

8/16/2026 at 4:28:51 PM

Not everything is a SaaS application. There's a lot of software where you only run one or two application servers.

by fabian2k

8/16/2026 at 2:53:13 PM

I’d argue this is not the right question. Obviously people use Postgres without PgBouncer. If you include non-production in the mix (CI/CD), most connections probably avoid it.

But because PgBouncer is so common, the question should probably be, why isn’t connection pooling part of Postgres out of the box? I think this might be the more interesting question.

by mbreese

8/16/2026 at 11:56:21 PM

That is the premise of the article. To wit:

If everyone needs it, is it really a non-core function?

by Yeroc

8/16/2026 at 2:08:17 PM

Yes. Sometimes PostgreSQL is overkill for a low traffic, simple application. PgBouncer would be even more overkill and add unnecessary complexity.

by theandrewbailey

8/16/2026 at 2:12:23 PM

[flagged]

by throwaway27448

8/16/2026 at 2:07:27 PM

If you don’t use serverless but instead a few (vertically scaling) servers, and your ORM / query builder supports pooling (all node libraries I’ve used have a pooler)…

Having a setup with just a simple docker deploy, running a monolith, not using pgbouncer so you can use LISTEN/NOTIFY to implement your own job queue:

https://www.dbos.dev/blog/postgres-listen-notify-scalability

This gives me warm fuzzy feelings, also making me relatively cloud-agnostic in the process, even though devops is not my strong point.

Most projects I do don’t need something more complex or vendor locked-in than this.

by grsmvg

8/16/2026 at 2:30:55 PM

For sure. I mean: many – if not most – people?

In my case, with Go, I have always relied on http://github.com/jackc/pgx pool, which works quite well, especially with the binary protocol.

by henvic

8/16/2026 at 2:07:42 PM

I guarantee you the vast majority of RDS instances aren't using RDS Proxy. For one, it's rather expensive.

by chuckadams

8/17/2026 at 7:36:18 AM

And it doesnt play reallt well with Aurora

by wreath

8/16/2026 at 5:50:26 PM

Totally agree. Postgres core should include connection pooling by default, and PgBouncer is probably the natural path to get there.

With PgBouncer addressing one of its biggest historical pain points - prepared statement support in transaction mode, in our managed Postgres offering, we’re increasingly seeing customers use the PgBouncer connection string by default for mose use-cases without running into any hiccups. That wouldn’t necessarily have been the case a few years ago.

PgBouncer is also battle-tested, widely validated, and offers a (surprising) level of configurability. You could also run a peered setup and make it multi-threaded, which is something I didn’t expect when I first came to know about it. https://news.ycombinator.com/item?id=48872874

by saisrirampur

8/16/2026 at 2:14:26 PM

of course, the vast, vast majority of PostgreSQL users outside of managed cloud hosting are not using pgbouncer. pgbouncer introduces complexities into the database conversation (transaction-level pooling interacting with the prepared statement cache is a long recurring nightmare for us at sqlalchemy) that often not worth the complexity for small local installations.

this article seems to be talking about commercial cloud managed PG services, which yes, those absolutely need to support connection pooling and of course they're going to use pgbouncer.

by zzzeek

8/16/2026 at 1:39:46 PM

Yes, I don't always need it. Depends on the service architecture.

by hoppp

8/16/2026 at 2:00:41 PM

Yes. I've never even heard of PgBouncer.

by 1over137

8/16/2026 at 2:13:53 PM

Me too. I even opened the page and I'm not sure of what's the problem being solved.

by LtWorf

8/16/2026 at 2:47:57 PM

Every single connection to Postgres is a new process, which requires a fork and new memory allocation (at least 10MB plus whatever you need for your query).

PgBouncer opens a pool of connections and then reuses them each time a client asks for a connection. This reduces latency (no more fork) and overhead (reuse memory).

by aobdev

8/16/2026 at 3:01:23 PM

If it's designed well, your application also opens a pool of connections and re-uses them each time the code needs a DB connection.

by gkbrk

8/16/2026 at 4:21:12 PM

The issue is language ecosystems that don't use client side connection pooling because they're single threaded (node, Python). So scaling up the number of web server threads means scaling the number of Postgres processes, which are expensive.

by mike_hearn

8/17/2026 at 12:59:13 AM

Python has threads and connection pools work fine on async workers as well.

by LtWorf

8/17/2026 at 9:31:49 PM

Yes but they can’t be shared. If you size your pool to hold 10 connections (because asyncio can handle that and more), then deploy with uvicorn —-workers 4 (which should match the number of cores on your app server), and then deploy to 3 app servers (for redundancy) then you’ve now got 120 open connections to Postgres. Run anything more than a trivial query and you’re easily at gigabytes of ram.

by aobdev

8/17/2026 at 10:38:07 PM

120 connections is likely fine. If it's not, you could do only 5 connections per worker. This is more of a problem if you have uneven load on the workers though.

by frollogaston

8/18/2026 at 12:45:22 AM

I’m not claiming it’s not fine, but it is a surprising consideration for a relatively small deployment. You have to start planning around Postgres’ architecture for anything larger, hence the solution in PgBouncer.

by aobdev

8/18/2026 at 8:47:43 AM

This is more app instances than 99% of deployments. Most apps and websites run a single server.

by gkbrk

8/16/2026 at 4:00:03 PM

This solves the latency but not the overhead--you'll end up with a full pool of connections for each running instance of your application.

by aobdev

8/16/2026 at 5:44:48 PM

How many running instances do you need though? e.g. Scala web frameworks should be able to do thousands of RPS on a single core without the application developer really trying to optimize anything, and I always hear that even Ruby, Python, etc. are also fast enough to be IO bound so you should just need 2 copies for redundancy, right? Then give each like 8-16 connections.

by ndriscoll

8/16/2026 at 4:15:56 PM

If I'm implementing my own connection pool, I'll certainly make the number of connections configurable.

by SoftTalker

8/16/2026 at 5:02:29 PM

That's fine but doesn't address the issue that PgBouncer does. Your application connection pool can multiplex all the connections needed in one application. PgBouncer can multiplex the connections across all applications (whether different apps or many instances of the same app).

by aobdev

8/16/2026 at 3:16:39 PM

If you handle database requests naively, every request to the database may open its own connection. This is a super simple approach but will exceed the amount of connections the database can or wants to handle concurrently.

One solution is to increase your app complexity and introduce a layer that manages connection pooling or queuing.

Or you can just keep your app naive and simple and put pgbouncer transparently in front of your DB. Even for multiple apps, so instead of every app increasing in complexity, reimplementing connection handling, you just have pgbouncer.

by Brotkrumen

8/16/2026 at 2:20:01 PM

This is the first time I've heard pgbouncer mentioned in 15 years. I didn't know it was still around.

by tjwebbnorfolk

8/16/2026 at 2:03:32 PM

PgBouncer? Don't even know er.

by mlnj

8/17/2026 at 10:39:41 PM

Oh my goodness lol

by frollogaston

8/16/2026 at 5:34:27 PM

> since neither IBM nor Oracle is a service that any self-respecting person not part of an enterprise sales cycle would actually use

Heh, snarky.

I guess (almost) everyone uses PgBouncer because they want to use a setup that will need the scaling needs of most users from the get-go, to avoid wasting support time.

Personally, I run without it due to a fairly small scale - I don't need more than about 128-256 connections max and for me a dedicated connection pooler (other than what's sometimes used app-side) would just add complexity.

At the same time, one could totally reasonably make the argument that if almost everyone uses it, then it SHOULD quite possibly be a built in feature, instead of a separate component - such a tighter integration would most likely bring the overall complexity down.

by KronisLV

8/16/2026 at 2:26:50 PM

What pgbouncer does is indeed core functionality. Compare Postgres to MySQL and sql server, where analogous standalone connection pools are rarely used. The fundamental reason pgbouncer needs to exist is Postgres’ utterly retrograde design. Other examples: xid wraparound, conflict with recovery, lack of undo space.

by georgewfraser

8/16/2026 at 2:29:26 PM

I wouldn't do it without pgbouncer. Asking for trouble when one day connections exceeds. It's just that you start with "oh I'll manage the pool from my app" and then you're stuck with either putting things into the app or tuning the pool for the other side-programs you need from the app.

by arjie

8/17/2026 at 5:09:03 PM

Why can't postgres move to thread-per-connection like MySQL? Most of us use connection pools with mysql but it's nice to have super-fast connectivity and know that load surges are handled that much better.

by kerblang

8/16/2026 at 2:14:02 PM

A whole bunch of Cloudflare clients run Postgres (self hosted) without pgbouncer (they use hyperdrive).

by achanda358

8/16/2026 at 3:29:10 PM

Clickbait post, already made the rounds on in other sites and was mercilessly torn to shreds. The answer is that millions do in production. PgBouncer is only needed for stateless backends, and even then, only under specific circumstances.

by ComputerGuru

8/16/2026 at 1:33:36 PM

Yes

by alexthedigger

8/17/2026 at 8:15:33 AM

I do. I run Postgres in the same server as the app in some apps, with no pgbouncer, no regret at all after 10+ years.

by drchaim

8/16/2026 at 2:57:05 PM

I currently run without pgbouncer, but I have at most 200 connections. 50 of them are just replication. I didn't want the complexity.

by fires10

8/16/2026 at 1:56:00 PM

Yes.

by barelysapient

8/16/2026 at 5:52:28 PM

I use the Ecto connection pool when using Elixir/Phoenix.

by recroad

8/16/2026 at 3:06:40 PM

I’m curius about pgcat, is there anyone here using it ?

by 131hn

8/16/2026 at 4:45:53 PM

We don't maintain it anymore. I'm working on pgdog[1] fulltime now. We've had several successful pgcat -> pgdog migrations now.

[1] https://github.com/pgdogdev/pgdog

by levkk

8/16/2026 at 2:00:49 PM

pgdog.

by ParadisoShlee

8/16/2026 at 2:38:16 PM

I mean… my self hosted Postgres with its ca 15 active connections certainly doesn't use PgBouncer, and it doesn't need to. But that was presumably not the intended scope of the question?

Then again, people forget you can just run your own Postgres (or anything really).

by eqvinox

8/16/2026 at 3:59:44 PM

The answer is: yes.

by throw1234567891

8/16/2026 at 3:47:07 PM

I use postgres. I've never heard of pgbouncer. So the answer is an easy Yes.

Saved you a click.

by nilamo

8/16/2026 at 1:39:35 PM

Are you kidding me? Have you heard about Data Direct?

https://docs.progress.com/bundle/datadirect-postgresql-odbc-...

by root-parent

8/16/2026 at 2:31:19 PM

DataDirect is not free but I guess we are discussing technical merits here. For them pooling happens in the connectivity layer and exposes proper pool controls such as minimum and maximum pool size, connection lifetime behavior, and optional connection state reset.

More importantly, it has capabilities that PgBouncer is not designed to provide. It can maintain alternate PostgreSQL servers, retry connections, randomize connection attempts across primary/alternate servers, and has explicit failover modes. The application retains a real PostgreSQL session while the driver handles connection reuse and failure handling.

That matters because of PgBouncer big technical compromise that is transaction pooling. This breaks the assumption that one client connection is the PostgreSQL backend session.

Consequently, several session scoped PostgreSQL features do not work normally in transaction pooling. PgBouncer own compatibility table, lists some of the limitations: https://www.pgbouncer.org/features.html

DataDirect does not need to solve that particular problem because its architecture does not perform that same transaction level back end swapping.

by root-parent

8/16/2026 at 11:28:52 PM

Am i the only one who still uses Pgpool ?

by bart3r

8/18/2026 at 1:37:30 PM

Nope, I'd take pgPool any day mostly for its load balancing abilities, not found on pgBouncer. I've never understood public fascination and favor of pgBouncer over pgPool despite this major omission. Perhaps it's because their unfamiliarity about its features and benefits.

Thanks for being the only pgPool comment ;)

by vladsanchez

8/16/2026 at 2:04:36 PM

Yes, except for serverless backend, you normally don't need it.

by lazyc97

8/12/2026 at 11:07:13 PM

[flagged]

by bakoserge

8/16/2026 at 3:29:48 PM

Transaction mode has one real footgun: SET statements are session-scoped, but in transaction mode your session gets reassigned between transactions. Easy to miss until you're chasing a mysterious search_path bug at 2am.

psycopg3 prepares statements by default now, which breaks in transaction mode unless you explicitly opt out.

For apps with a persistent server process and an in-app pool the external bouncer is mostly ceremony. The math changes with serverless: no persistent process means no persistent pool, so a dedicated pooler starts pulling its weight.

by saadyousfi

8/16/2026 at 11:33:12 PM

[flagged]

by blackbriar75

8/16/2026 at 5:02:13 PM

We run asyncpg directly against Neon Postgres without PgBouncer — works well for low-to-medium concurrency. Neon's serverless connection pooling handles a lot of what PgBouncer would, so the overhead didn't seem worth it for our use case.

by CodeWithLeo

8/16/2026 at 1:31:33 PM

[dead]

by Arsen-V

8/16/2026 at 3:16:16 PM

[flagged]

by fenestella

8/16/2026 at 9:44:23 PM

This account is an AI bot - check its history. It generates a summary of each article to generate a plausible comment to build up an account reputation. Flagged.

by pocksuppet

8/16/2026 at 7:30:32 PM

I am also curious if anyone here has any anecdotal experience with transitioning away from an independent pooler after the v14+ improvements to connection management.

by booleanbetrayal