4 ms·

"With policies, your database becomes the rules engine. Instead of repetitively filtering your queries, you can simply define a rule on your database table, aut

"With policies, your database becomes the rules engine. Instead of repetitively filtering your queries, you can simply define a rule on your database table, auth.uid() = user_id, and your request will return the rows which pass the rule, even when you remove the filter from your middleware." I'm not sure how I feel about this. With something like authorization, being explicit is better than implicit. This makes it far too easy for someone to accidentally forget a policy configuration, but it looks like all your other queries so it passes code review, and now you have a data breach. But could be that I'm missing something in how this actually works. Would love to get your thoughts on it.

whalesalad 6y ago
I agree. I would not secure user data with row-level security inside the DB itself. That’s an application concern and it should live in your application layer. It also limits you from replacing the underlying storage engine later on, if you decide PostgreSQL is not the answer. I find this to be an unwise architectural decision.
- rvense 6y ago
  But why can Postgres not be promoted to the "application level"? If you combine it with a few extra tools like an auth service and an HTTP API adapter, the need for custom backend code is reduced or removed. Your backend is created declaratively through the schema and policies can be exposed directly to clients. I have been thinking about this a lot, recently, due to working on a greenfields project where I was allowed to think all the foundational architectural decisions of my past projects through. It's struck me how much of the tedious code I've written in my career has been due to a few features in database systems that were either missing or unknown to me (mainly related to auth and validation). Supabase is exactly the kind of system I have been working towards. You can use Postgres as a dumb datastore, but you'll be replicating a lot of functionality at the "application level" that Postgres already has. And if you're serious about being able to swap it out for another database, you'll either be writing a lot of abstractions, or foregoing some of its great features (e.g. its JSON datatypes) in order to not become too joined to it. Creating more work for yourself due to some unknown situation that might arise in the future strikes me as an even more unwise decision than tying yourself to a flexible, well-known, and proven open source project. It seems no different than tying yourself to React or Docker or whatever.
  - whalesalad 6y ago
    > But why can Postgres not be promoted to the "application level"? Anything is possible. It can be done. My personal/professional opinion is that you are shooting yourself in the foot by eliminating what is otherwise a very handy abstraction between your business machinery and the underlying system that stores the data.
    - programmarchy 6y ago
      That’s not really a handy abstraction though, because you ain’t gonna need it. The exception being you scale past Postgres in which case you’re going to need a new architecture anyway. Way better to leverage the robust tooling that Postgres provides rather than rolling your own. Bravo to Supabase for having the technical insight to bring that leverage to the mainstream.
kiwicopple 6y ago
It's worth noting that you don't _have_ to use RLS. This just give you the option to if you don't want to do it on the application level (like Firebase). You should try it out though - it's very cool when you see it in action

whalesalad 6y ago

I agree. I would not secure user data with row-level security inside the DB itself. That’s an application concern and it should live in your application layer. It also limits you from replacing the underlying storage engine later on, if you decide PostgreSQL is not the answer. I find this to be an unwise architectural decision.

rvense 6y ago
But why can Postgres not be promoted to the "application level"? If you combine it with a few extra tools like an auth service and an HTTP API adapter, the need for custom backend code is reduced or removed. Your backend is created declaratively through the schema and policies can be exposed directly to clients. I have been thinking about this a lot, recently, due to working on a greenfields project where I was allowed to think all the foundational architectural decisions of my past projects through. It's struck me how much of the tedious code I've written in my career has been due to a few features in database systems that were either missing or unknown to me (mainly related to auth and validation). Supabase is exactly the kind of system I have been working towards. You can use Postgres as a dumb datastore, but you'll be replicating a lot of functionality at the "application level" that Postgres already has. And if you're serious about being able to swap it out for another database, you'll either be writing a lot of abstractions, or foregoing some of its great features (e.g. its JSON datatypes) in order to not become too joined to it. Creating more work for yourself due to some unknown situation that might arise in the future strikes me as an even more unwise decision than tying yourself to a flexible, well-known, and proven open source project. It seems no different than tying yourself to React or Docker or whatever.
- whalesalad 6y ago
  > But why can Postgres not be promoted to the "application level"? Anything is possible. It can be done. My personal/professional opinion is that you are shooting yourself in the foot by eliminating what is otherwise a very handy abstraction between your business machinery and the underlying system that stores the data.
  - programmarchy 6y ago
    That’s not really a handy abstraction though, because you ain’t gonna need it. The exception being you scale past Postgres in which case you’re going to need a new architecture anyway. Way better to leverage the robust tooling that Postgres provides rather than rolling your own. Bravo to Supabase for having the technical insight to bring that leverage to the mainstream.

kiwicopple 6y ago

It's worth noting that you don't _have_ to use RLS. This just give you the option to if you don't want to do it on the application level (like Firebase). You should try it out though - it's very cool when you see it in action