I'm curious, with Supabase being all in on postgres, why (IIUC) doesn't it use postgres users and roles for user access control. RLS is great, and users/roles allow for column-based access control as well. Was there some practical limitation of using postgres users that caused issues? I know that you'd still have to have the secondary table (auth.users) since the postgres users table won't have all the columns you need. Perhaps social authentication isn't reasonable when you're using a pg user?

Interesting topic, and not something I've ever really thought about. I wonder if the choice to use JWT is a reason, or like you say, maybe the typical users and groups support in PG doesn't allow enough flexibility for social auth. Interested to hear what other people think or for some more info.

JWT makes perfect sense, I'm happy with that. I just wonder if things could also be better done in a "postgres" way if the users were backed by regular postgres users. It could unlock certain types of role-based stuff that could be pretty neat.

I think using DB users as app users adds more complexity and a security challenge as DB users have access to a much broader set of privileges. They are also global to the db cluster and probably can't be managed within the context of a single db deployment.

That's helpful insight. Yeah, if they're global to the cluster that would make things pretty challenging in some contexts.