--- title: Does anyone run Postgres without PgBouncer? | daily.dev description: Almost every notable managed Postgres provider bundles a connection pooler like PgBouncer, according to a survey of major providers including AWS RDS, Azure,... canonical: https://daily.dev/posts/does-anyone-run-postgres-without-pgbouncer--kpfxapce0 twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Does anyone run Postgres without PgBouncer? | daily.dev og:description: Almost every notable managed Postgres provider bundles a connection pooler like PgBouncer, according to a survey of major providers including AWS RDS, Azure,... og:url: https://daily.dev/posts/does-anyone-run-postgres-without-pgbouncer--kpfxapce0 og:image: https://api.daily.dev/og/posts/kPFXAPcE0.png og:image:alt: Does anyone run Postgres without PgBouncer? og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Does anyone run Postgres without PgBouncer? **[Lobsters](https://daily.dev/sources/lobsters)** · 4 min read · 55 upvotes · 9 comments ## Summary Almost every notable managed Postgres provider bundles a connection pooler like PgBouncer, according to a survey of major providers including AWS RDS, Azure, Google Cloud SQL, Supabase, Neon, DigitalOcean, and others. Only IBM Cloud and Oracle OCI lack a managed pooling option, and both are dismissed as unlikely choices outside enterprise sales cycles. The piece argues connection pooling is effectively a mandatory add-on because Postgres itself handles many connections poorly, and contrasts this with MySQL and MongoDB, which don't require a bolted-on pooler. The wasted effort of every provider building homegrown pooling setups and every user having to learn PgBouncer's quirks (like the lack of LISTEN/NOTIFY support) is framed as evidence that native connection pooling in Postgres itself would be a high-impact improvement. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### which managed postgres providers include pgbouncer or a connection pooler by default Most major managed Postgres providers bundle a pooler out of the box, including Aiven, Alibaba RDS, Azure PG, Crunchy Bridge, DigitalOcean, EDB Postgres AI, Fly.io MPG, Neon, PlanetScale, Railway, Render, Supabase, and Tiger Cloud, nearly all using PgBouncer. AWS RDS/Aurora uses a separate RDS Proxy service, Google Cloud SQL requires Enterprise Plus, and Supabase offers PgBouncer or its own Supavisor for serverless. Only IBM Cloud and Oracle OCI ship without any managed pooler. _Comparing managed Postgres options on pooling support is easier with daily.dev's coverage of database infrastructure trade-offs._ ### why does postgres need a connection pooler like pgbouncer Postgres handles large numbers of concurrent connections poorly because each connection spawns a full OS process rather than a lightweight thread, making it expensive at scale. PgBouncer and similar poolers sit in front of Postgres to multiplex client connections into a smaller set of database connections, but require understanding pooling modes and limitations, such as not supporting LISTEN/NOTIFY properly in transaction pooling mode. _Developers weighing Postgres connection strategies can track pooling trade-offs and best practices on daily.dev._ ## Community take How the wider developer community reacted, aggregated from 2 discussions and 36 comments across hackernews, lobsters (as of 2026-09-14). **TL;DR:** Many developers say pgbouncer is only needed once you hit real connection-limit scale, with smaller workloads running fine without it, while a deep side-thread debates whether Postgres's process-per-connection model versus lack of multiplexing is the real underlying issue. **Sentiment:** 10% positive · 55% mixed · 35% skeptical **The case for** - Several people report running Postgres for years at moderate scale (dozens of connections) with zero need for a pooler. - Client-side connection pooling (e.g. Hikari) is cited as a viable alternative that keeps things under connection limits without pgbouncer's quirks. - One provider employee notes many support tickets come from misusing pgbouncer transaction mode rather than from Postgres itself lacking pooling. **The pushback** - A recurring criticism is that Postgres's per-connection process model handles many connections poorly compared to MySQL's threading. - Several argue the deeper problem is Postgres's lack of native multiplexing, not the process-vs-thread distinction. - pgbouncer in transaction mode breaks features like session-level SET, search_path changes, and tools like Prisma or pg_dump. - One person described pgbouncer silently holding transactions open for hours, contributing to a production incident, after which they removed it without issue. **By community** - hackernews (mixed): No comments were provided, so little signal beyond the story being posted. - lobsters (mixed): Discussion splits between those who find pgbouncer essential at scale and those who never needed it, alongside a long technical tangent on process vs. thread scheduling and multiplexing. **Hottest debate:** Whether Postgres's core weakness is its process-per-connection model or simply its lack of connection multiplexing. **Open questions** - Would native multiplexing in Postgres actually eliminate the need for tools like pgbouncer, or just shift the sharp edges elsewhere? - At what connection count or workload pattern does pooling become genuinely necessary versus optional? **Highlights** > As someone who runs pgbouncer at scale and [contributes](https://github.com/pgbouncer/pgbouncer/pulls?q=is%3Apr+author%3Acosgroveb+is%3Aclosed) to it, this article's title is a little disappointing. As with most engineering decisions you should weigh the tradeoffs and while Postgres doesn't have multiplexing out of the box you do need to know where the sharp edges are here and how to [grasp them](https://jpcamara.com/2023/04/12/pgbouncer-is-useful.html). The author at least links to a provider doc on [when not to use pgbouncer](https://jpcamara.com/2023/04/12/pgbouncer-is-useful.html) although even that source makes blanket recommendations that are truly situational. For instance, batch processing through pgbouncer can be useful provided you use dedicated pools, tuned for the workload. Session-specific features... Yeah, this is one where blanket "don't do this" is better than no advice but you can do it in transaction-pooling mode on a feature-specific basis with workarounds (like `DISCARD ALL` [server_reset_query](https://jpcamara.com/2023/04/12/pgbouncer-is-useful.html)). This is a good read for when you need to know the sharp edges, [when and how to wear gloves](https://jpcamara.com/2023/04/12/pgbouncer-is-useful.html). > Postgres is great. PgBouncer is important. Know what can go wrong and account for it. Commenters [here](https://lobste.rs/c/e85xnq) [note](https://lobste.rs/s/xic1nn/does_anyone_run_postgres_without#c_iv8kgv) healthy scale where they have never needed pgbouncer. That's the right outlook. It's not like MySQL multi-plexing doesn't have roughly the same set of [sharp edges](https://planetscale.com/blog/connection-pooling?utm_source=chatgpt.com#connection-settings). It's just built-in which seems to be the author's main criticism? > MySQL provides a wide range of session-level system settings that can be adjusted for each connection. However, when using connection pooling, all connections in the pool share the same settings. Any modifications made to a connection will render it unusable for other requests, as it becomes "tainted". > — [brian on lobsters · 1 points](https://lobste.rs/s/xic1nn/does_anyone_run_postgres_without#c_txc9db) > It was a while ago, so I don't remember the details I'm afraid. It was the application opening what *should* have been a short-lived transaction, but pgbouncer just sometimes held it open. We pulled out pgbouncer to mitigate the immediate incident, then discovered it wasn't giving us anything in the first place. Have been running bare PostgreSQL since, for a couple of years, without issues. > — [duncan\_bayne on lobsters · 2 points, 1 comments](https://lobste.rs/s/xic1nn/does_anyone_run_postgres_without#c_6wdv3x) > - automation scripts that set the search path - Frameworks such as Prisma : my possibly flawed understanding is that under certain operations they can set the transaction mode to read only - pgdump - giving individual users who log in with the same role the same pgbouncer connection string to do whatever they want over it - literally anything that uses `set` and probably some more I've forgotten. To be clear - these are problems when you use pgbouncer *in transaction mode* > — [OPBoot on lobsters · 2 points](https://lobste.rs/s/xic1nn/does_anyone_run_postgres_without#c_0ivckx) **Source threads** - [hackernews](https://news.ycombinator.com/item?id=49277952) · 8 points · 0 comments - [lobsters](https://lobste.rs/s/xic1nn/does_anyone_run_postgres_without) · 31 points · 36 comments ## Community discussion Top comments from developers on daily.dev. **@agustinbarrientos** · 3 upvotes > I think Postgres should expose a pooled endpoint natively, while keeping a direct endpoint for LISTEN/NOTIFY and session-state workloads. **@trevorsuna** · 3 upvotes > The strongest case for native pooling is not just connection overhead, but semantics. Every team eventually has to learn which session features break in transaction mode. A built-in pooler could make those tradeoffs explicit and versioned with Postgres itself. **@hardik15** · 2 upvotes > Sadly I even don't know what is pgBounser, though I am deploying it for years on a cloud. **@rizzdev** · 2 upvotes > The one url one port wish holds until the process model. MySQL hides the pooler because threads share memory. Postgres still pays a backend per connection even with the listener inside the binary and the C extensions that assume process isolation all have to be rewritten before that wish actually ships **@ajaychoudhary80** · 1 upvotes > The fragmentation across managed providers shows how much operational complexity is being pushed onto users. ## Similar posts on daily.dev - [Everyone into the Pool](https://daily.dev/posts/everyone-into-the-pool-mo3kijgek) · Planet PostgreSQL · 0 upvotes · 0 comments - [Google Introduces Managed Connection Pooling for AlloyDB](https://daily.dev/posts/google-introduces-managed-connection-pooling-for-alloydb-3jt7lyzbz) · InfoQ · 0 upvotes · 0 comments - [Understanding the differences between PgBouncer and Amazon RDS Proxy for PostgreSQL connection pooling](https://daily.dev/posts/understanding-the-differences-between-pgbouncer-and-amazon-rds-proxy-for-postgresql-connection-pooli-gx5neceyc) · AWS Database Blog · 0 upvotes · 0 comments - [The Deep End](https://daily.dev/posts/the-deep-end-yjgj5j5bn) · Planet PostgreSQL · 0 upvotes · 0 comments - [Sharing is \(not always\) caring. PgBouncer pooling modes in practice.](https://daily.dev/posts/sharing-is-not-always-caring-pgbouncer-pooling-modes-in-practice--4dfgv5c5q) · Event-Driven by Oskar Dudycz · 0 upvotes · 0 comments --- Tags: [#database](https://daily.dev/tags/database), [#postgresql](https://daily.dev/tags/postgresql) [View this post on daily.dev](https://daily.dev/posts/does-anyone-run-postgres-without-pgbouncer--kpfxapce0) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Does anyone run Postgres without PgBouncer?","url":"https://daily.dev/posts/does-anyone-run-postgres-without-pgbouncer--kpfxapce0","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/does-anyone-run-postgres-without-pgbouncer--kpfxapce0"},"datePublished":"2026-08-13T12:59:08.883Z","dateModified":"2026-09-14T06:55:19.429Z","description":"Almost every notable managed Postgres provider bundles a connection pooler like PgBouncer, according to a survey of major providers including AWS RDS, Azure,...","image":"https://media.daily.dev/image/upload/s--qPvKM23u--/f_auto/v1722860399/public/Placeholder%2009","thumbnailUrl":"https://media.daily.dev/image/upload/s--qPvKM23u--/f_auto/v1722860399/public/Placeholder%2009","isAccessibleForFree":true,"articleSection":"Lobsters","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Lobsters","logo":"https://media.daily.dev/image/upload/s--tl8v_Fku--/f_auto,t_logo/v1698841318/logos/lobste.jpg","url":"https://daily.dev/sources/lobsters"},"commentCount":9,"discussionUrl":"https://daily.dev/posts/does-anyone-run-postgres-without-pgbouncer--kpfxapce0","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":55},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":9}],"keywords":"database,postgresql","timeRequired":"PT4M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Lobsters","item":"https://daily.dev/sources/lobsters"},{"@type":"ListItem","position":3,"name":"Does anyone run Postgres without PgBouncer?"}]} {"@context":"https://schema.org","@type":"WebPage","@id":"https://daily.dev/posts/does-anyone-run-postgres-without-pgbouncer--kpfxapce0","comment":[{"@type":"Comment","text":"I think Postgres should expose a pooled endpoint natively, while keeping a direct endpoint for LISTEN/NOTIFY and session-state workloads.","datePublished":"2026-08-13T22:14:04.578Z","url":"https://daily.dev/posts/kPFXAPcE0#c-TenMtNwD3","author":{"@type":"Person","name":"Agustin Barrientos","url":"https://daily.dev/agustinbarrientos","image":"https://media.daily.dev/image/upload/s--5ayxQnqn--/f_auto/v1788281802/avatars/avatar_wQYYVe5Tbj0NJ7C7qPoa8?_a=BAMAMicg0"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":3}},{"@type":"Comment","text":"The strongest case for native pooling is not just connection overhead, but semantics. Every team eventually has to learn which session features break in transaction mode. A built-in pooler could make those tradeoffs explicit and versioned with Postgres itself.","datePublished":"2026-08-14T06:22:10.314Z","url":"https://daily.dev/posts/kPFXAPcE0#c-JtHihTNp9","author":{"@type":"Person","name":"Trevor Suna","url":"https://daily.dev/trevorsuna","image":"https://media.daily.dev/image/upload/s--dZ7gXxpp--/f_auto/v1784081551/avatars/avatar_EMoP47rpuw8DNjhp6R1b6?_a=BAMAMicg0"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":3}},{"@type":"Comment","text":"Sadly I even don’t know what is pgBounser, though I am deploying it for years on a cloud.","datePublished":"2026-08-15T09:33:51.701Z","url":"https://daily.dev/posts/kPFXAPcE0#c-aEazYEd5o","author":{"@type":"Person","name":"Hardik","url":"https://daily.dev/hardik15","image":"https://media.daily.dev/image/upload/s--O0TOmw4y--/f_auto/v1715772965/public/noProfile"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":2}},{"@type":"Comment","text":"The one url one port wish holds until the process model. MySQL hides the pooler because threads share memory. Postgres still pays a backend per connection even with the listener inside the binary and the C extensions that assume process isolation all have to be rewritten before that wish actually ships","datePublished":"2026-08-14T11:18:51.147Z","url":"https://daily.dev/posts/kPFXAPcE0#c-VGT5XdTjV","author":{"@type":"Person","name":"Andrew","url":"https://daily.dev/rizzdev","image":"https://media.daily.dev/image/upload/s--35vRfXAA--/f_auto/v1785413727/avatars/avatar_fQ7ttCKtPuu6tDvcgQXv5?_a=BAMAMicg0"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":2}},{"@type":"Comment","text":"The fragmentation across managed providers shows how much operational complexity is being pushed onto users.","datePublished":"2026-08-18T05:03:55.708Z","url":"https://daily.dev/posts/kPFXAPcE0#c-6awLMJHor","author":{"@type":"Person","name":"Ajay Choudhary","url":"https://daily.dev/ajaychoudhary80","image":"https://media.daily.dev/image/upload/s--WkX8wDW2--/f_auto/v1780989706/avatars/avatar_QNZlI2SgVnNSx5PSRpCVx?_a=BAMAMiWQ0"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":1}}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/does-anyone-run-postgres-without-pgbouncer--kpfxapce0#faq","mainEntity":[{"@type":"Question","name":"which managed postgres providers include pgbouncer or a connection pooler by default","acceptedAnswer":{"@type":"Answer","text":"Most major managed Postgres providers bundle a pooler out of the box, including Aiven, Alibaba RDS, Azure PG, Crunchy Bridge, DigitalOcean, EDB Postgres AI, Fly.io MPG, Neon, PlanetScale, Railway, Render, Supabase, and Tiger Cloud, nearly all using PgBouncer. AWS RDS/Aurora uses a separate RDS Proxy service, Google Cloud SQL requires Enterprise Plus, and Supabase offers PgBouncer or its own Supavisor for serverless. Only IBM Cloud and Oracle OCI ship without any managed pooler. Comparing managed Postgres options on pooling support is easier with daily.dev's coverage of database infrastructure trade-offs."}},{"@type":"Question","name":"why does postgres need a connection pooler like pgbouncer","acceptedAnswer":{"@type":"Answer","text":"Postgres handles large numbers of concurrent connections poorly because each connection spawns a full OS process rather than a lightweight thread, making it expensive at scale. PgBouncer and similar poolers sit in front of Postgres to multiplex client connections into a smaller set of database connections, but require understanding pooling modes and limitations, such as not supporting LISTEN/NOTIFY properly in transaction pooling mode. Developers weighing Postgres connection strategies can track pooling trade-offs and best practices on daily.dev."}}]} ```