I think the best part is that if you're willing to go all in on RLS for your authorization, you can do away with needing a backend for your typical crud operations and use their functions for things like webhooks, or the occasional endpoint for more complicated operations.
I am a happy paying user of supabase and I did just that for my project which is meant to facilitate trading of left over wood between woodworker shops. I simply set RLS rules and now I only have a react frontend which calls supabase directly and it works great.
I haven't checked in a while but one thing that was a little cumbersome for me was that I wasn't familiar with writing proper RLS rules and felt like documentation was a bit sparse and iirc there was not autocomplete to guide me a little more - but that might just be me being an idiot and it worked out with a little trial and error. :)
I would say it's definitely one of the missing pieces in their documentation. They have an example policy for the typical scenario of only allowing a user to read/update/delete their own resources, but there's definitely more patterns that are needed. One that took me a bit to figure out on my own was how to only allow a user access to a resource gated behind a subscription (ie a column value in a table).
I can't quite get onboard with RLS directly from the client. It seems like a risky and finicky thing to design database access patterns around, but they might be a stroke of genius that I'm too blind to see right now.
If you're not comfortable then that's totally ok, especially because it's not as easy to test it automatically, but it's definitely allowed me to do away with a backend completely except for a webhook, so that's been nice.
