Anyone use supabase in production for about 10k read / write in short period of time (e.g. 1 minute) ? can it scale ? I come from firestore, so I don't have to worry about this. Should I worried using supabase ? looks like they have limit on memory / cpu usage.

As I said, there's a lot of factors to consider, even with simple queries. Take a look at https://blog.crunchydata.com/blog/postgresql-13-benchmark-memory-speed-vs.-tps This shows that with 60 clients, it is possible to scale to around 200,000 transactions per second. As for some real world examples, here's some figures I've managed to handle: - 438K row inserts via

COPY

in 7 seconds - 39 million row inserts via

COPY

in 2m 34s In both cases, the tables were set to

unlogged

and indexes were dropped before the

COPY

is executed, and then indexes are recreated and table set to

logged

after the

COPY

is complete. Postgres is more than capable of scaling up to very high levels, but again, each use case is different so everyone will attain different results.

@Scott P do i have to worry about supabase ram dan cpu usage?

I'd honestly advise you to try it with your specific use case and find out. It's impossible to give a yes or no answer because every project is different

What happened when cpu and ram maxed out? Does supabase have auto scaling? I am talking about managed supabase here

I'm using a self-hosted version, so I can't answer that question. Honestly, the best way to find out if it'll work for your use case is to try it.

I don't understand how scaling in supabase works.. can anyone help me? Is is elastic and scales automatically when on load or is it allocated fixed resources If so what are the resources available to us according to the tier

how do you scale horizontally using self hosted ?

This isn't something I've done, but typically with Postgres, you'd have a primary DB alongside replicas or shards, and a load balancer sat in front of the infrastructure (https://www.highgo.ca/2021/08/09/horizontal-scalability-options-in-postgresql/ covers some options). I'm not sure how well that approach integrates with Supabase, but I think you'd potentially create multiple copies of your Supabase stack (including the already-populated database, as well as the auth, rest, realtime, storage and containers), and then after they're setup, configure the replication, and have a load balancer sat in front. It might even be possible to spin up copies of the entire stack with K8S and then automate it to configure replication or sharding after the new instances are spun up.

Any updates to this - is there any guide to scaling supabase services in self-hosted? I only see in the docs (https://supabase.io/docs/guides/hosting/overview) that Kubernetes is coming soon. For now, can we scale the containers for self-hosting?