Thank you for this write up - it's extremely actionable. Our team is already chatting about it internally to find some quick wins, and we'll do a deep-dive tomorrow on each of the items you've raised.
Some easy ones from me:
> RBAC is completely missing
We are implementing something here, but we need to find the right level of abstraction for all/most use-cases. It's still unclear to us whether we should make this simply documentation ("RBAC with RLS") or actually build the abstraction. We have built something internally which we are dogfooding, so watch this space.
> Stored procedures are more likely to be utilized in the Supabase paradigm
Now that we have released Edge Functions, we have more time to work on the blend between both Procedures and Functions. Our CLI needs a lot of work, but this will be a major focus for the rest of the year.
> They clearly have work ahead of them, but I'm optimistic about the potential for Supabase and I look forward to the improvements!
With regards to authorization – have y'all looked any at Open Policy Agent[1]? I think it could potentially be a good fit for the Supabase stack to implement policies not just in the database but also the gateway and potentially other components as well.
It'd be super cool to be able to implement custom policies in rego code that could be re-used in several parts of the stack, and tested/verified/evolved independently from the stack.
We did evaluate OPA recently. For now, we're working with an approach that builds on top of PostgreSQL Row Level Security and functions. That may have a sufficient balance of power, performance and complexity for many of our users. For more complex use cases, OPA may indeed be a good fit and is something we can explore more in the future.
Some easy ones from me:
> RBAC is completely missing
We are implementing something here, but we need to find the right level of abstraction for all/most use-cases. It's still unclear to us whether we should make this simply documentation ("RBAC with RLS") or actually build the abstraction. We have built something internally which we are dogfooding, so watch this space.
> Stored procedures are more likely to be utilized in the Supabase paradigm
Now that we have released Edge Functions, we have more time to work on the blend between both Procedures and Functions. Our CLI needs a lot of work, but this will be a major focus for the rest of the year.
> They clearly have work ahead of them, but I'm optimistic about the potential for Supabase and I look forward to the improvements!
Thanks for the kind words!