A cloud-native, multi-tenant Postgres connection pooler.
2.2k
Stars
112
Forks
44
Open issues
29
Contributors
AI Analysis
Supavisor is a cloud-native, multi-tenant Postgres connection pooler written in Elixir that proxies millions of client connections into managed Postgres database pools. It is purpose-built for cloud environments requiring zero-downtime scaling, serverless workload support, and efficient resource utilization—serving infrastructure teams and platform operators at scale, not general-purpose application developers.
Inferred from signals mentioned in the README (tests, CI, type safety) — not a review of the actual code.
AI's overall editorial judgment — not an average of the bars above, can weigh other factors too.
Elixir-native Postgres pooler designed for cloud-scale multi-tenant environments, not a PgBouncer replacement.
Supavisor is a cloud-native Postgres connection pooler written in Elixir, built by Supabase to handle millions of connections across multi-tenant deployments. It targets serverless-era connection patterns and aims to decouple pooling from database instance resources. Adoption appears limited to Supabase's own infrastructure and early adopters; real-world production deployments outside Supabase are not well-documented.
Created January 2023 as part of Supabase's infrastructure evolution. Designed to solve specific scaling problems Supabase encountered: zero-downtime Postgres resizing, absorption of millions of short-lived serverless connections, and multi-tenant isolation. Represents a deliberate architectural choice to move pooling outside the database instance.
Gained 2,227 stars over ~3.5 years—modest growth relative to other Supabase projects. Last 7 days show 12 stars gained; last push was June 26, 2026 (7 days ago from analysis date), indicating active recent work. Growth pattern suggests stable internal use at Supabase with slow but steady external interest rather than viral adoption.
Adoption not verified outside Supabase infrastructure. README and public signals do not document adoption by known third parties or public case studies. Supabase likely runs Supavisor internally for its managed Postgres offering, but this is inferred from architecture, not explicitly stated. No prominent production deployments mentioned in discoverable documentation.
Appears to be a clustered, distributed architecture where tenant connection pools are dynamically created on cluster nodes and registered in-memory across the cluster. Based on README: uses external Postgres for tenant config storage, monitors pool processes per node, handles failover by redistributing pools to remaining nodes. Designed for multi-node deployments in cloud environments (VPC, multi-AZ). Likely supports transaction-mode pooling per README; session pooling listed as future work.
Not documented in README. Coverage badge visible in README suggesting CI/CD integration, but coverage percentage not stated.
Last push June 26, 2026 indicates active maintenance as of analysis date. Repository created January 2023; ~3.5 years of continuous existence. Metadata shows 110 forks and ongoing development. Appears to be regularly maintained rather than stagnant, though growth rate is gradual. No evidence of abandonment.
ADOPT IF: you operate a managed Postgres platform or need multi-tenant connection pooling at cloud scale (millions of connections, multi-node resilience required), have capacity to run a dedicated pooler cluster, and accept the operational burden of distributed systems. AVOID IF: you need a simple, single-node drop-in replacement for PgBouncer, prefer battle-tested tools with 15+ years of production history, or lack experience with Elixir and distributed clustering. MONITOR IF: you are building a Postgres-as-a-service platform, facing connection exhaustion from serverless workloads, or considering alternative architectures to co-located pooling—Supavisor represents a legitimate design choice but adoption and ecosystem maturity remain early.
Independent dimensions
Mainstream potential
3/10
Technical importance
7/10
Adoption evidence
2/10
- Adoption not verified: real-world production usage outside Supabase is undocumented; risk of being primarily internal infrastructure without a vibrant external user base.
- Operational complexity: requires running a multi-node cluster with distributed state management; higher operational bar than PgBouncer or single-node poolers.
- Language choice (Elixir): narrows pool of operators and contributors familiar with language; fewer DevOps engineers trained on Elixir deployment vs. C (PgBouncer) or Rust (pgcat).
- Early-stage features: several key features listed in 'Future Work' (load balancing, query caching, session pooling, HA management) remain unimplemented; uncertain when/if they ship.
- Limited external documentation and case studies: no public benchmarks vs. competitors, no detailed operational runbooks from production users outside Supabase; makes it harder to assess real-world performance and tradeoffs.
Supavisor will likely remain a specialized tool for cloud-native, managed Postgres platforms rather than become a universal PgBouncer alternative. It may see adoption among other managed database services or large-scale serverless environments, but mainstream adoption appears unlikely due to operational complexity and lack of broad ecosystem push. Continued maintenance by Supabase is probable; growth will remain modest.
Newsletter
Get analyses like this every Monday
Free weekly digest of the most interesting open-source discoveries.
Languages
Information
- Language
- Elixir
- License
- Apache-2.0
- Last updated
- 14h ago
- Created
- 42mo ago
- Analyzed with
- anthropic/claude-haiku-4-5
Stars over time
Contributors over time
Top 100 contributors only — repos with more will plateau at 100.
Similar repos
| Repository | Stars | Week Δ | Language | Score | Updated |
|---|---|---|---|---|---|
|
supabase/supavisor
this
|
2.2k | +9 | Elixir | 8/10 | 14h ago |
|
supabase/supabase
|
106.1k | — | TypeScript | 9/10 | 1h ago |
|
supabase/storage
|
1.3k | — | TypeScript | 8/10 | 13h ago |
|
supabase/supabase-js
|
4.5k | — | TypeScript | 8/10 | 10h ago |
|
supabase/realtime
|
7.6k | — | Elixir | 8/10 | 1d ago |
|
supabase/supabase-swift
|
1.3k | — | Swift | 8/10 | 16h ago |
Supavisor explicitly targets scenarios where PgBouncer has limitations: cloud-scale (millions of connections), multi-tenant isolation, zero-downtime resizing, and separation of pooling from database instance resources. PgBouncer is single-node, resource-constrained when co-located with database, and not designed for serverless patterns. Supavisor trades single-node simplicity for cluster complexity.
pgcat (also Rust-based, high-performance pooler) solves similar single/multi-tenant pooling problems but appears more focused on performance-per-node rather than cluster-scale multi-tenancy and distributed failover.
Citus handles distributed Postgres but is primarily a data distribution layer, not a pure connection pooler; targets different use case (sharding vs. connection management).
Some organizations layer HAProxy for load balancing in front of PgBouncer clusters; Supavisor attempts to solve this in a single, coordinated system but requires operational complexity of a distributed cluster.
Other managed Postgres platforms likely have similar pooling infrastructure; Supavisor appears designed for Supabase's specific architecture and may not be easily portable to other cloud contexts.
