Yep, I'm aware of the ability to revoke permissions, it's the design choice of "allow by default" that worries me - but I agree this is a Supabase thing, not PostgREST.
On a new project, if you look at the dashboard (pointing at an existing db) access to all tables and data is on by default, you have to explicitly deny access to those tables. That's a concerning design choice for my industry (healthcare).
> PostgREST also encourages you to create a dedicated schema for your api[2].
Yes, it does - but this isn't really called out strongly by Supabase (not PostgREST's fault).
As some other commenters mentioned, it's not a big deal to create views in the api schema, and I agree. The part I'm still evaluating is whether there will be actual time savings and efficiency vs just creating CRUD endpoints in NodeJS (for example).
The big "win" for PostgREST here is the ability to do deep querying and result shaping directly from the UI without needing to create a bunch of custom endpoints. If I have to create views anyway, it seems like I lose a lot of the benefits of using PostgREST in the first place, and add a layer of complication to the stack.
I like PostgREST a lot, and I've been hoping that Supabase would be an effective Directus replacement (now that Directus has gone closed source), but I'm still figuring out whether the juice is worth the squeeze on my project.
Would love any insight you or others have from using it in production with a medium-scale sized app.
Yep, I'm aware of the ability to revoke permissions, it's the design choice of "allow by default" that worries me - but I agree this is a Supabase thing, not PostgREST.
On a new project, if you look at the dashboard (pointing at an existing db) access to all tables and data is on by default, you have to explicitly deny access to those tables. That's a concerning design choice for my industry (healthcare).
> PostgREST also encourages you to create a dedicated schema for your api[2].
Yes, it does - but this isn't really called out strongly by Supabase (not PostgREST's fault).
As some other commenters mentioned, it's not a big deal to create views in the api schema, and I agree. The part I'm still evaluating is whether there will be actual time savings and efficiency vs just creating CRUD endpoints in NodeJS (for example).
The big "win" for PostgREST here is the ability to do deep querying and result shaping directly from the UI without needing to create a bunch of custom endpoints. If I have to create views anyway, it seems like I lose a lot of the benefits of using PostgREST in the first place, and add a layer of complication to the stack.
I like PostgREST a lot, and I've been hoping that Supabase would be an effective Directus replacement (now that Directus has gone closed source), but I'm still figuring out whether the juice is worth the squeeze on my project.
Would love any insight you or others have from using it in production with a medium-scale sized app.