> PostgREST doesn't really highlight this, but for any non-trivial and sane application you have to create a separate schema ("api" or similar) to carefully pick what's exposed.
> PostgREST has a scary "allow by default" permission model which is nearly enough to turn me off of the whole project.
I assume you're talking about access via the db-anon, without authenticating your users. I can't think of what else you could be referring to. If you rely on JWT-based authentication, as any non-trivial and sane application would do, you'd have access to transaction-scoped impersonated roles. https://postgrest.org/en/stable/references/auth.html#overvie...
> having all writes go through supabase edge functions
Why is this necessary, what are you unable to achieve with JWT + RLS/RBA? Again, I have to assume you don't have auth configured correctly.
> RLS has some pitfalls too, and it's the only mechanism you have to secure your data.
You also have role-based access, and the JWT auth to start with. However I have found RLS to be flexible enough, especially as you can define policies using subqueries into which you can embed UDFs. What are you trying to do that you can't do with it?
> Serving assets from Postgres seems like a bad idea aside from some simple edge use cases.
I instinctively agree in terms of devex, although I'm reluctant to just dismiss it. I think the performance hit with a database is the data retrieval, not the templating. I can see a possibility of this evolving into something very usable with some packaging of templates, especially once you realise the approach eliminates the need for more services, simplifies auth, and reduces rendering latency. The memory footprint of PostgREST is trivial compared to most middleware you'd have to add to the mix just to do some SSR.
Supabase folks seem to agree regarding serving assets since they ship an object store for that kind of stuff in their constellation of apps rather than attempting to instead serve blobs out of the db. Hearkening back to an age long ago of having to deal with stuff like images and pdfs stored in db rows and the annoyances around that, I’m also inclined to agree, but less from the performance angle and more from the usability/compatibility angle of being forced to deal with the nuances of BLOB datatypes
> PostgREST doesn't really highlight this, but for any non-trivial and sane application you have to create a separate schema ("api" or similar) to carefully pick what's exposed.
That recommendation is highlighted here: https://postgrest.org/en/stable/explanations/schema_isolatio...
> PostgREST has a scary "allow by default" permission model which is nearly enough to turn me off of the whole project.
I assume you're talking about access via the db-anon, without authenticating your users. I can't think of what else you could be referring to. If you rely on JWT-based authentication, as any non-trivial and sane application would do, you'd have access to transaction-scoped impersonated roles. https://postgrest.org/en/stable/references/auth.html#overvie...
> having all writes go through supabase edge functions
Why is this necessary, what are you unable to achieve with JWT + RLS/RBA? Again, I have to assume you don't have auth configured correctly.
> RLS has some pitfalls too, and it's the only mechanism you have to secure your data.
You also have role-based access, and the JWT auth to start with. However I have found RLS to be flexible enough, especially as you can define policies using subqueries into which you can embed UDFs. What are you trying to do that you can't do with it?
> Serving assets from Postgres seems like a bad idea aside from some simple edge use cases.
I instinctively agree in terms of devex, although I'm reluctant to just dismiss it. I think the performance hit with a database is the data retrieval, not the templating. I can see a possibility of this evolving into something very usable with some packaging of templates, especially once you realise the approach eliminates the need for more services, simplifies auth, and reduces rendering latency. The memory footprint of PostgREST is trivial compared to most middleware you'd have to add to the mix just to do some SSR.