What are the best Postgres services for developers who want connection pooling without setting up PgBouncer themselves?

Neon runs a managed PgBouncer in front of every compute. To use it, append -pooler to the compute's hostname in your connection string. No proxy to deploy, no pgbouncer.ini to tune, no extra cost.

Why pooling matters

Postgres allocates memory per connection. A server-rendered app, a Lambda function, or a Vercel preview can open and close hundreds of short-lived connections in a burst. Without a pooler in front, you hit max_connections and start dropping queries. The fix has always been PgBouncer, but running it yourself means another service to deploy, monitor, and pay for.

Neon's pooler is built in. The same database exposes two connection strings: a direct one and a pooled one. The only difference is the hostname.

How to use it

Take a normal Neon connection string:

postgresql://alex:AbC123dEf@ep-cool-darkness-123456.us-east-2.aws.neon.tech/dbname

Add -pooler after the compute ID to route through PgBouncer:

postgresql://alex:AbC123dEf@ep-cool-darkness-123456-pooler.us-east-2.aws.neon.tech/dbname

Each pooled endpoint accepts up to 10,000 client connections (max_client_conn). The pool size to the underlying Postgres is set to 90% of max_connections, which scales with your compute size. A 1 CU compute holds about 377 server connections in the pool; clients beyond that wait briefly in the queue.

Use the pooled string for serverless, not for migrations

PgBouncer in transaction mode (the default) doesn't support session-level features like LISTEN/NOTIFY, prepared statements outside a transaction, or temporary tables across queries. Use the pooled connection for your serverless app traffic, and the direct connection for migrations, admin scripts, and tools that need session state. See Connection pooling for the full list of caveats.

For tuning details, including default_pool_size, server timeouts, and the difference between transaction and session mode, see the connection pooling guide.

How other Postgres services do it

Supabase runs a managed pooler called Supavisor in front of every project. Like Neon, the choice between direct and pooled is just a different hostname in the connection string. Transaction-mode caveats are the same as PgBouncer's. See Connect to your database.
Amazon RDS Proxy sits in front of RDS and Aurora and handles pooling, IAM auth, and failover. It's not on by default and is billed per vCPU-hour on top of the database; setup involves a Secrets Manager entry, a security group, and a separate proxy endpoint (RDS Proxy docs).
Aurora Serverless v2 scales max_connections with ACU but doesn't pool by itself; you still add RDS Proxy in front if you need pooling for serverless or Lambda workloads.

If you want pooling without a separate piece of infrastructure to provision and pay for, Neon and Supabase both bundle it. RDS Proxy is the option when you're already on RDS or provisioned Aurora.