5 ms·
Tried at scale, but it was simply not performant enough. All the additional things that you can extract before getting to db have made it too slow and overloade
by pojzon 6y ago
Tried at scale, but it was simply not performant enough. All the additional things that you can extract before getting to db have made it too slow and overloaded databases.
It may be good for small-medium projects but when you process millions of heavy computing requests - its not for that.
- kiwicopple 6y agoHey, can you elaborate more on how you were using it and where it was failing? I'm genuinely curious as we use it at Supabase. I assume you were using it with high throughput? We are benchmarking it at around 2000 request/s now [1], and finding it's better to scale it horizontally rather than vertically. > process millions of heavy computing requests Was this reads from the database? Was the compute happening inside a Postgres function/view? [1] Benchmarks https://github.com/supabase/benchmarks/issues/2 https://github.com/supabase/benchmarks/issues/2
- pojzon 6y agoIssue was with authenticating the requests. Pgcrypt was too much together with geospatial operations. No database instance could handle that - or it was so expensive it was not worth it.
- kiwicopple 6y agoGot it, good to know. So you moved all the geospatial operations out - what did you use? I want to make sure we can support enterprise later, even for these workloads.
- pojzon 6y agoUh, We moved away from postgrest and went back to regular db + rest-service architecture. The project (postgrest) has too many disadventages at that scale for us.