Am i the only one who still uses Pgpool ?
Does anyone run Postgres without PgBouncer?
91–100 of 121 posts
Re: Does anyone run Postgres without PgBouncer?
#92[flagged]
Re: Does anyone run Postgres without PgBouncer?
#93Article 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,…
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/databas…
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.
Re: Does anyone run Postgres without PgBouncer?
#94(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 r…
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
Lol, linking your own comments is pretty weird
Re: Does anyone run Postgres without PgBouncer?
#95I’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.
That is the premise of the article. To wit:
If everyone needs it, is it really a non-core function?
Re: Does anyone run Postgres without PgBouncer?
#96Earlier quoted context omitted.
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" adja…
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 mo…
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.
Re: Does anyone run Postgres without PgBouncer?
#97Earlier quoted context omitted.
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.
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.
Python has threads and connection pools work fine on async workers as well.
Re: Does anyone run Postgres without PgBouncer?
#98(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 r…
Can you add more on why Pgbouncer is limited in a multi-tenant environment?
Re: Does anyone run Postgres without PgBouncer?
#99This 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…
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.
I believe it would add color to the discussion if you enumerated a few of the details of those workloads.
Re: Does anyone run Postgres without PgBouncer?
#100This 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…
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.