6 ms·

I like the approach Supabase takes in being a light abstraction over Postgres and using OSS. Even in light of the following critiques, I feel like its one of t

I like the approach Supabase takes in being a light abstraction over Postgres and using OSS. Even in light of the following critiques, I feel like its one of the simplest ways for an experienced developer to start a new project, and it's now my go to over spinning up a database, Firebase, ORMs, and other database abstractions. My main critiques are: - 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. - 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. - 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. - Escape hatches are missing in their fork of GoTrue (why did they fork it in the first place - now there are two competing versions?). It's still not clear to me how to add data to the JWT or get access to the JWT through their SDK. - Slow dashboard with rendering problems. It doesn't render correctly on my Fedora laptop. And the slow speed becomes pretty annoying almost right away. - I have experienced data loss when using their SQL editor. So now I copy all the SQL I write to a local file or just do everything through DBeaver. - Lack of backups on the free tier. They should give this away for free up to a storage limit. Backups are a critical part of development and I don't have full trust in Supabase given that I've already experienced data loss through their UI. - Misleading marketing. They make implicit claims all over the place on what they offer but then have disclaimers on their code bases about certain features not being production ready. They clearly have work ahead of them, but I'm optimistic about the potential for Supabase and I look forward to the improvements!

kiwicopple 4y ago
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! Thanks for the kind words!
- ehathaway 4y ago
  Thanks for the reply! Also, is there any plan on the horizon to have the cloud offering support Google or Azure? Id love the option to use a different provider than AWS.
  - kiwicopple 4y ago
    Yes, that's the plan. Probably not this year, more likely next year at the current rate
- mstade 4y ago
  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. [1]: https://www.openpolicyagent.org/ https://www.openpolicyagent.org/
  - thebengeu 4y ago
    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.
michelpp 4y ago
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 4y ago
  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 4y ago
    > 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 4y ago
These are all valid critiques I feel. I would also add something that's currently a pretty glaring hole in the Supabase offering: migrations. Is far as I know there's no good current advice for how to do staged environments and migrating between them with Supabase. Most advice I've seen is to use Prisma (or similar) which means you have to accept having an ORM layer in the stack, or to use a script that really just applies SQL scripts in a certain order, and puts a lot of the onus on the developer to make sure they get those migration scripts right. We've been getting by with diffing our environments and doing mostly manual migrations, but it's not going to scale and we're mostly just trying to avoid doing DB chances at all instead. It's not easy coming up with a one-size-fits-all migration story for sure, but I feel this one is pretty important and not having any good guidance to offer on migrations is a big piece missing I feel. All in all though, Supabase has a great product and the company is very responsive both in terms of support and acting on community contributions. This investment is very well deserved and as a customer I'm very happy indeed to see this news!
- Shorn 4y ago
  For me, this is the part where Supabase being purely a Postgres implementation is a real strength. Supabase gives you access to the underlying database directly via a standard Postgres connection, so you can use literally any tool you want for database migrations. Downside to the direct access being that there's no pretty Web UI for it - but I think that's both a pro and con (it sometimes bothers me how much effort they put into their UI, from an purely opportunity-cost perspective).

kiwicopple 4y ago

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! Thanks for the kind words!

ehathaway 4y ago
Thanks for the reply! Also, is there any plan on the horizon to have the cloud offering support Google or Azure? Id love the option to use a different provider than AWS.
- kiwicopple 4y ago
  Yes, that's the plan. Probably not this year, more likely next year at the current rate
mstade 4y ago
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. [1]: https://www.openpolicyagent.org/ https://www.openpolicyagent.org/
- thebengeu 4y ago
  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.

michelpp 4y ago

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 4y ago
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 4y ago
  > 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 4y ago

These are all valid critiques I feel. I would also add something that's currently a pretty glaring hole in the Supabase offering: migrations. Is far as I know there's no good current advice for how to do staged environments and migrating between them with Supabase. Most advice I've seen is to use Prisma (or similar) which means you have to accept having an ORM layer in the stack, or to use a script that really just applies SQL scripts in a certain order, and puts a lot of the onus on the developer to make sure they get those migration scripts right. We've been getting by with diffing our environments and doing mostly manual migrations, but it's not going to scale and we're mostly just trying to avoid doing DB chances at all instead. It's not easy coming up with a one-size-fits-all migration story for sure, but I feel this one is pretty important and not having any good guidance to offer on migrations is a big piece missing I feel. All in all though, Supabase has a great product and the company is very responsive both in terms of support and acting on community contributions. This investment is very well deserved and as a customer I'm very happy indeed to see this news!

Shorn 4y ago
For me, this is the part where Supabase being purely a Postgres implementation is a real strength. Supabase gives you access to the underlying database directly via a standard Postgres connection, so you can use literally any tool you want for database migrations. Downside to the direct access being that there's no pretty Web UI for it - but I think that's both a pro and con (it sometimes bothers me how much effort they put into their UI, from an purely opportunity-cost perspective).