How to load test the dB for max number of connections
I asked support about how many users could be actively using the site and while I haven't received anything tangible back, the documentation that I was directed to suggested load testing.
Is there a programmatic way to try to simulate a whole bunch of users doing the kinds of activities that go on at my site to see where the line is, specifically, for me, before I'd hit my caps?
I feel like if a Pro plan can sustain 500 people real-time, and my in-app calls are pretty modest, that that might be an analogue. It's my understanding that realtime uses different resources, but if it's all under the same instance, that seems healthy.
I also think it's unlikely to quickly arrive at a point where that many users are on simultaneously but it's good to know what the plan is ahead of time.
It just makes me nervous because I get flashbacks to WordPress hosts and PHP workers mysteriously disappearing after you already signed up with the host and everything running like caca.
(I don't suspect Supabase is going to do anything but improve, I just mean finding out the hard way without anything concrete or usable information-wise as far as when the generous resources crap out and perhaps necessitate an upgrade)
4 Replies
realtime is totally different than connections to do database accesses. The new realtime is a separate cloud infrastructure not running on your instance at all (except for the database calls it makes to validate RLS and the replication bandwidth.
I've seen benchmarks with hundreds to low thousand requests per second thru PostgREST database API. Of course the complexity of your requests will impact that greatly.
https://github.com/supabase/benchmarks/issues/8
GitHub
End-to-end Benchmark · Issue #8 · supabase/benchmarks
Chore As part of our move from Alpha to Beta, we will want to be clear about the limitations and performance of each of the components in Supabase. In this benchmark, we want to load test the full ...
Thanks for the clarification, and also the link -- support tried sharing one with me but it was broken; perhaps this is the one they meant.
As a layperson I am not sure how to parse the logs; my inference would be that they're trying the "data sent" as a POST to the database and "data received" is the return from the database, and that the totals are the grand total of that same packet X number of times.
I am also still not sure what the guidance would be to a client I am representing to help guide her about decisions to protect against high activity disrupting site activities.
I did see this elsewhere online which is helpful to think about, once/if I can establish similar benchmarks for my own instance (greatly aided by the mention of tools in that thread, so thank you again)
Most applications operate on a ‘connection pool’ model. So if you have 100 connections in your pool(s), it really doesn’t matter for this discussion if it is 1 server with 100 connections to the database, or 10 with 10 each. Each connection is going be grabbed from the pool when a request needs to make a query. The query will take some amount of time, N. You can have 100 queries, and thus 100 connections, working at any given time. So, 100/N is the rate, and if N is in milliseconds, and supposing it was 50, then you can work about 2 queries per millisecond, or about 2000 queries per second.
and also this snippet from the PgBouncer blog announcement
If your clients is running expensive queries then the connections might take a long time before they are returned to the pool. The natural solution to this is to increase your database resources so that it processes queries faster or PgBouncer can open more connections.
in case that's useful to anyone else.Database calls thru the REST API (using PostgREST) don't use PgBouncer. PostgREST has its own pooler. FYI.
That's starting to make one dimension of this make a lot more sense.
https://supabase.com/docs/guides/platform/performance shows 90 connections for my Small Pro plan, and that's also what shows in
https://app.supabase.com/project/_______/database/roles but the pricing page says 30/75 direct/pooler. It is good to know that they're different things.
If those 90 are pooled, that's encouraging. I appreciate all of your help.
It looks like later in the docs it actually recommends k6.
I think the last missing piece would just be figuring out how to understand what comes back to know what to upgrade to.