supavisor VS pgbouncer

WalEx instead of pub/sub (listen/subscribe): https://github.com/cpursley/walex

Supavisor connection pooler: https://github.com/supabase/supavisor

To make use of your read replicas, copy your connection string for the read replica, update your apps to use the new read replica and you are done! A unique connection pool is also provisioned for each read replica via Supavisor.

[I'm on the supabase team]

You can find the code/docs here: https://github.com/supabase/supavisor

This release adds support for

- SQL Parsing

- Load balancing

- support for named prepared statement

- query cancellation

It's also now available on all new databases in Supabase. For some more background on scalability, we have some benchmarks available here:

https://supabase.com/blog/supavisor-1-million

PgBouncer maintainer here, so obviously biased. But I think currently PgBouncer should still be the default connection pooler that you choose. There's a few newer options: Odyssey, pgcat, and supavisor. But all focus on a solving 1 or 2 specific problems that PgBouncer did not solve well, while not solving many of the other problems that PgBouncer does solve. So if you have the exact same requirements as the authors of those tools, then switching might be good. But otherwise you should probably continue using PgBouncer.

Supavisor specifically is really immature. It's missing some really core functionality like query cancellations: https://github.com/supabase/supavisor/issues/174

I did a talk on this exact topic at PGConf NYC recently. My slides are here: https://github.com/JelteF/slides/raw/main/2023-10-05-future-...

If you are interested in exploring Supavisor's potential or want to implement its scalability in your upcoming project, check out the GitHub repository to know more.

Phoenix.PubSub is basically a noop service. It really just works. You should try it!

If discovering nodes is difficult in your env, try using a listen/notify libcluster strategy:

https://github.com/supabase/supavisor/blob/main/lib/cluster/...

[2] https://github.com/supabase/supavisor

Supavisor

Thanks to MongoDB drivers all consistently providing connection monitoring and pooling functionality, external connection pooling solutions aren't required (ex: Pgpool, PgBouncer). This allows applications built using MongoDB drivers to be resilient and scalable out of the box, but based on what we understand regarding the number of connections applications establish to MongoDB clusters it stands to reason that at a certain point as our application deployments increase, so will our connections.

Pgbouncer - resolvia o problema do limite de conexões no postgres. Mas a API “saudável” manteve o número de conexões baixo o suficiente.

Pgbouncer maintainer here. Overall I think this is a great description of the tradeoffs that PgBouncer brings and how to work around/manage them. I'm actively working on fixing quite a few of the issues in this blog though

1. Named protocol-level prepared statements in transaction mode has a PR that's pretty close to being merged: https://github.com/pgbouncer/pgbouncer/pull/845

A common solution is connection pooling. Supabase currently offers pgbouncer which is single-threaded, making it difficult to scale. We've seen some novel ways to scale pgbouncer, but we have a few other goals in mind for our platform.

Great observation! :)

We worked upstream to have `search_path` properly handled (tracked per client) by pgbouncer.

https://github.com/pgbouncer/pgbouncer/commit/8c18fc4d213ad4...

Check config.md in that commit for a verbose, humanized description.