We still have a few benchmarks to complete, but PostgREST has been thoroughly tested now. Steve just spent the past month improving throughput on PostgREST, with amazing results (50% increase).
tldr: for simple GET requests on a t3a.nano you can get up to ~2200 requests/s with db-pooling.
Thanks! It's amazing what you can get done with optimization vs horizontal scaling.
What would you say are the current failure modes? Say for a t3a.nano, what combination of payload size/queue length/rps/other parameters would absolutely mandate an upgrade in capability?
I couldn't tell you with a reasonable degree of unfortunately. We will do some stress testing at some point, but we haven't started them yet.
We see few 500 errors across all of the PostgREST requests at Supabase. The errors that I can remember are from users doing `select=*` on tables which would return hundreds of MB of data. If you're thinking of adopting it then we'd be happy to help figure out if it's the right tool for your use-case.
We still have a few benchmarks to complete, but PostgREST has been thoroughly tested now. Steve just spent the past month improving throughput on PostgREST, with amazing results (50% increase).
tldr: for simple GET requests on a t3a.nano you can get up to ~2200 requests/s with db-pooling.