supavisor
bugzino
supavisor | bugzino | |
---|---|---|
15 | 1 | |
1,582 | 12 | |
1.8% | - | |
8.9 | 2.2 | |
17 days ago | about 1 year ago | |
Elixir | Kotlin | |
Apache License 2.0 | - |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
supavisor
-
PostgreSQL Is Enough
WalEx instead of pub/sub (listen/subscribe): https://github.com/cpursley/walex
Supavisor connection pooler: https://github.com/supabase/supavisor
-
Introducing Read Replicas
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.
-
Supavisor 1.0: a scalable connection pooler for Postgres
[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 1.21.0 released with prepared statement support
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-...
-
Supavisor: Scaling Postgres to 1 Million Connections
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.
-
How to Listen to Database Changes Using Postgres Triggers in Elixir
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/...
-
The Database Package Manager for PostgreSQL Trusted Language Extensions
[2] https://github.com/supabase/supavisor
-
Supabase Logs: open source logging server
Supavisor
- Supavisor - Postgres connection pooler written in Elixir
- Supavisor - a Postgres connection pooler written in Elixir
bugzino
-
The Database Package Manager for PostgreSQL Trusted Language Extensions
At KotlinConf today I gave a talk on designing apps with two-tier architecture, where you implement your entire app without the web stack appearing anywhere at all. Instead you publish desktop and mobile apps that connect directly to an RDBMS like PostgreSQL via its native protocol, and use server extensions for any logic that is inconvenient to do with SQL.
This approach might seem horrifyingly outside-the-box but has a lot of advantages, and some of the reasons we didn't do things this way historically have been solved in recent years.
Because it was KotlinConf the demo uses PL/Java, which is pretty nice because there's such a healthy ecosystem of stuff based around JDBC and because deploying JVM stuff doesn't require any sort of cross-compilation. PL/Java also supports (for now) trusted extensions using sandboxing, although of course the sandbox can just get in the way and normally you trust your own server anyway so this is a double edged sword.
The demo code can be found here (it's a prototype and nobody reviewed it yet so be gentle)
https://github.com/hydraulic-software/bugzino
I'll write up a blog post version of the talk, but for now I had to mention that DBaaS providers don't actually enable this sort of design because they like to wall off the full power of the RDBMS behind custom APIs. But in two-tier design you really lean into the database and use all of its features. So, it'd be nice if:
a. database.dev were to support PL/Java extensions.
b. Supabase were to allow direct connections, as the native DB protocol supports a lot of features that otherwise have to be sort of hacked on top of HTTP. Ultimately, HTTP is designed to fetch hypertext whereas the PG native protocol is designed to work with data, and that difference shines through in a bunch of ways.
What are some alternatives?
pgcat - PostgreSQL pooler with sharding, load balancing and failover support.
pgress - Native PostgreSQL JavaScript client library for web browsers
pg_tle - Framework for building trusted language extensions for PostgreSQL
mssql-changefeed
set_user - PostgreSQL extension allowing privilege escalation with enhanced logging and control
debezium - Change data capture for a variety of databases. Please log issues at https://issues.redhat.com/browse/DBZ.
sql-examples - Curated list of SQL to help you find useful script easily 🚀
walex - Postgres change events (CDC) in Elixir
cainophile
omnigres - Postgres as a Platform
Logflare - Never get surprised by a logging bill again. Centralized structured logging for Cloudflare, Vercel, Elixir and Javascript.