Hacker News Reader

Comment by derefr | Hacker News Reader

Anyone here using this in production? I’ve always thought it was a neat idea, but haven’t heard of anyone building their API-oriented-SaaS company around it.

View on HN

I've used it for admin tools at real jobs. And once powered a read only "consumer" (writes came from offline webscraping) hobby project with it to make a no-backend-code react app. I see no reason it couldn't work in prod, especially if you had a CDN or HTTP cache in front.

What I found most striking is that it relies on postgres for just about everything. Content obviously (sometimes straight from tables, sometimes via db views), but also users and permissions. I'd first assumed there would be a config file a mile long but it really is all Postgres.

We're using it at CYPEX to automatically make customer data consumable for our frontend.

https://www.cybertec-postgresql.com/en/products/cypex/

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.

Hey, 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

Issue 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.

Got 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.

Uh, 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.

I recently read that supabase.io is using this. https://supabase.io/docs/postgrest/server/about

We've used this in production for geospatial data delivery via GKE cloud run. Worked quite well.

It looks like, there are a few already using this in production

You can see it on this page: http://postgrest.org/en/v7.0.0/

Reply on news.ycombinator.com