supavisor VS sql-examples

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

If you decide to do this we should put it on database.dev - i'm sure it would be very popular

database.dev fills the same role for PostgreSQL as npm for JavaScript or pip for Python, it enables publishing libraries and applications for repeatable deployment. Our goal is to create an open ecosystem for packaging and discovering SQL.

Supabase just wrapped up their Launch Week 7 with a ton of incredible features. This includes an AI assistant that was added to their premium platform. It is aware of your database design and can help you when creating more complex SQL queries. I'm even more thrilled by their most recent releases of outstanding open source projects, such as the PostgreSQL package manager database.dev. dbdev serves the same purpose for PostgreSQL that npm does for JavaScript. It gives your PostgresSQL database incredibly easy access to packages that give your DB superpowers like full-text search or one-time-only-read data access à la Snapchat. The best thing is that dbdev can load any PostgreSQL instance that has the required fundamental extensions, independent of the Supabase platform. Again, the code is open source. I can't wait to see where this project goes in the future, and I have no doubt that we will soon be able to utilize a lot more fantastic libraries. Like Brandon Roberts puts it:

hi hn!

supabase engineer and author of dbdev here

happy to answer questions

If you're looking for a next step after reading the article, checkout the available packages on https://database.dev

(shameless plug) https://database.dev/olirice/asciiplot is a fun one to play around with if you have some queries that could use optimization

I'm really looking forward to opening dbdev up to community packages in the coming weeks

https://database.dev/ Database for SQL commands - great for backend engineers!

If you - find it useful, please spare a 🌟 at the Github Repo If you - found any issue/bug, create issues is much appreciated. If you - wanted to contribute the SQL scripts, PR is even more welcomed!