Supavisor: Scaling Postgres to 1M Connections
In this technical retrospective (2023), @inian shares practical architectural lessons learned from running, scaling, or migrating production software under lean constraints.
Core Principles for Independent Builders:
Defaulting to simpler architectures (such as monolithic frameworks, SQLite, or managed VPS) prevents early engineering bankruptcy.
Evaluating true compute and egress costs reveals that high cloud bills can often be slashed by 80%+ through judicious re-platforming.
Code you write at 2 AM as a solo engineer must be easy to debug six months later without complex microservice dependencies.
Community Debate Themes:
HN engineers debated the tradeoffs between cloud convenience and raw server economics, database indexing strategies, and resisting premature architectural complexity.
CATEGORY Frugal Engineering →
HISTORICAL ERA Post-ZIRP & AI (2023–2026)
COMMUNITY SCORE 14 points
TOTAL DISCUSSIONS 1 comments
supabase dev here...
this was a very fun load test to run. happy to answer any questions.
shoutout to José Valim and the Dashbit team for the help on Supavisor. elixir and erlang are amazing tools.
connection limits, even with pgbouncer, have been a big support burden for us. supavisor should let us be more liberal with connections we allot to folks.
supavisor is rolled out and available for all projects to use today. contact support[0] and we can expose the supavisor connection string in your dashboard. we'll be proactively exposing it to everyone gradually over the next ~1 month. we'll run pgbouncer and supavisor both for you for probably ~5 months before you need to switch to supavisor.
also very excited at the potential features a custom postgres proxy can unlock.
[0] https://supabase.com/dashboard/support/new ↗
supabase engineer here
would be happy to answer questions about load testing setup
here is the github repo[0] with an app that helps me launch terraforms and k6 and keep track of launches/results
[0]https://github.com/supabase/benchmarks ↗
Maybe I’m reading this wrong, but an additional 2ms latency on every query seems pretty unacceptable to me. Do you have any plans to mitigate this downside?