In the dynamic world of database management, the limitations of connection systems can be a hurdle for developers aiming to scale their applications seamlessly. Enter Supavisor, the game-changing Postgres connection pooler developed by Supabase. In this blog post, we'll explore the intricacies of Supavisor, its architecture, benchmarking results, and the impact it promises to have on the scalability of Postgres clusters.
The Need for Scalable Connection Pooling
Postgres, while a robust and feature-rich database, faces challenges when it comes to handling a large number of connections. Each connection carries a significant memory footprint, making it tricky to determine the optimal number of connections a database can handle. Traditional solutions like pgbouncer have their limitations, often struggling to scale efficiently.

Introducing Supavisor
Supavisor, developed in partnership with José Valim and the Dashbit team, is designed to be a scalable, cloud-native Postgres connection pooler. Built with multi-tenancy in mind, Supavisor can gracefully handle millions of connections without introducing significant overhead or latency. What sets Supavisor apart is its ability to scale both vertically and horizontally, making it a powerful tool for applications requiring extensive database interactions.
Benchmarking the Unseen Potential

To validate Supavisor's capabilities, the Supabase team conducted extensive benchmarking, pushing the limits to one million concurrent connections. Using a custom load-testing application on AWS, the team assessed Supavisor's performance under various scenarios.
Establishing a Baseline
In the initial test, a single Supavisor instance with 16 cores and 32GB RAM handled 250,000 concurrent connections, processing 20,000 queries per second (QPS). This set the foundation, demonstrating the capacity of a single Supavisor instance.
Scaling Vertically
The team then tested Supavisor's vertical scaling capabilities, connecting 500,000 concurrent users to a 64-core Supavisor instance. Remarkably, QPS remained constant at 20,000, showcasing that increased connections didn't compromise Supavisor's performance.
Scaling to One Million Connections
Taking scalability a step further, Supavisor demonstrated its horizontal scaling prowess by successfully handling 1,003,200 simultaneous connections across two 64-core instances. The load was evenly distributed, with one instance directly connected to the database and the other relaying queries.
Impact on Query Duration
Supavisor's impact on query duration was assessed by testing with 5,000 queries per second. The results were impressive, with a median query duration of less than 2ms. Even at 20,000 QPS, the median query duration only increased to 18.4ms, highlighting Supavisor's efficiency.
Supavisor in Action
Comparing Supavisor with the existing PgBouncer setup, the Supabase team observed minimal impact on query duration. Supavisor proved to be a reliable alternative, introducing just an additional 2ms per query compared to PgBouncer.
Getting Started with Supavisor
Supavisor has been seamlessly integrated into all Supabase projects across regions. Developers can now harness the power of Supavisor by reaching out to support for connection details. The transition from PgBouncer to Supavisor is a smooth process, ensuring minimal disruption.
The Future with Supavisor
Supavisor's impact extends beyond Supabase, as it opens doors for developers aiming to build scalable applications. Its compatibility with multi-tenancy, Elixir-based architecture, and ability to handle millions of connections position it as a tool of choice for the future of Postgres connection pooling.
Conclusion
Supavisor stands as a testament to innovation in database management, addressing the challenges posed by traditional connection systems. As the Supabase team continues to push boundaries, Supavisor emerges as a beacon for developers seeking unparalleled scalability and performance in their database interactions. Dive into the world of Supavisor and unlock the true potential of your Postgres clusters.