[michelpp]

I work at Supabase on database security so I can speak to some of these.

> - As others have said, default security is way too permissive. They should lock everything down by default. At some point, this is going to cause major problems for some company that decides to build off Supabase.

We agree and are internally actively discussing this very subject.

> - Although they have row-level security, RBAC is completely missing. It's not hard to implement yourself through stored procedures and triggers (they have an example repo to copy from), but I don't see a lot of junior devs doing this.

We don't "have" row level security per se, that is a native feature of Postgres we expose, and the customer is free to use or not. RBAC is a very broad term, and broadly speaking Postgres has roles and privileges that do access control. Did you have something more specific in mind?

> - Stored procedures are more likely to be utilized in the Supabase paradigm, but I haven't felt like they have done much to address the inherent weakness and common critiques of using sprocs instead of application level functions.

Weaknesses, critiques and strengths. There are tradeoffs and some of this gets down to a matter of opinion. Mine is admittedly radical in this case. We recently released Edge functions which are great, more tools in the toolbox, including stored procedures.

Did you used to work on Zope? You have a familiar handle...

[ehathaway]

Thanks for the reply!

I've never worked at Zope. Must be my doppelganger.

> We don't "have" row level security per se, that is a native feature of Postgres we expose, and the customer is free to use or not. RBAC is a very broad term, and broadly speaking Postgres has roles and privileges that do access control. Did you have something more specific in mind?

I was referring to the ability to assign a user to one or more groups and then set, at the group level, access to a row or column. When I implemented this, I avoided using PG roles b/c I was unsure how this play safely with future changes to the hosted DB.

[michelpp]

> I've never worked at Zope. Must be my doppelganger.

Same last name and first initial as your handle so I took a guess. :)

> I was referring to the ability to assign a user to one or more groups and then set, at the group level, access to a row or column. When I implemented this, I avoided using PG roles b/c I was unsure how this play safely with future changes to the hosted DB.

This can be done with Postgres' built-in role system. You can assign a "group role" to as many roles as you want (which in turn, can also be groups, or not) into a hierarchy of roles which can be used in any GRANT statement or RLS policy. Postgres used to have `CREATE USER ...` and `CREATE GROUP ...` but they are now completely subsumed by the "new" role system. Both statements still work and map to equivalent `CREATE ROLE ...` statements.

[mstade]

As a Supabase user this statement from OP resonates with me:

> When I implemented this, I avoided using PG roles b/c I was unsure how this play safely with future changes to the hosted DB.

I don't know if they meant this exactly, but the way I interpret that is that there's a "fear" of sorts that by using PG features like roles there's a chance we might be doing things that are in conflict with things Supabase needs to do to effectively manage the database. The auth schema for example is effectively managed by Supabase and we shouldn't mess with it – but it's not necessarily clear where other boundaries are.

I've not come across a situation yet where we've done something in the database that conflicts with Supabase management, but it'd be nice to have some more clarity on what to avoid.

Maybe prefixing the Supabase managed schemas is a good place to start, but I'd also like to see some rules about settings we shouldn't mess with, features that should be avoided/used with care etc.

[qwertyzxcvmnbv]

Zope's Hathaway is S ;-)