// the find
supabase/supavisor
A cloud-native, multi-tenant Postgres connection pooler.
Supavisor is Supabase's Postgres connection pooler, built as a distributed Elixir/Erlang cluster instead of a single process like PgBouncer. It's meant for people who need pooling to survive node failures and scale horizontally, which is Supabase's own use case running it at serverless-scale connection counts.
The hot-path Postgres wire protocol parsing is offloaded to a Rust NIF (native/pgparser) rather than done in pure Elixir, which is the right call for throughput. The internals are genuinely production-hardened, not a toy: circuit breaker with sliding window, connect backoff with its own janitor process, a prepared-statement cache with pluggable LRU/random eviction, and a dead port sweeper. Ops tooling is built in rather than bolted on — Prometheus metrics, an OpenAPI spec with SwaggerUI, and Erlang hot-upgrade/relup support for zero-downtime releases. It's also not just a paper design; Supabase runs it in production at the scale claimed in the benchmarks.
Session pooling — PgBouncer's other primary mode — is still listed under 'Future work' and unimplemented; anything relying on session-scoped state like advisory locks or SET statements across queries can't use this yet, only transaction mode. Read-replica load balancing and automatic primary failover, which the README cites as core motivations for the project, are also still 'todo' — the HA story is aspirational, not shipped. Its own local pgbench numbers show it's marginally slower than PgBouncer (189 vs 196 tps, worse connection setup time), so the 'Fast' claim only holds at cluster scale, not as a single-node replacement. And it's an Elixir/Erlang codebase — fine if you're comfortable with BEAM, but a team that wants to self-host and actually modify it (versus run it as a black box) needs that expertise, unlike PgBouncer or pgcat.