Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Migrating from Supabase

blog.val.town

Post reply on HN
Print view View original

41–50 of 136 posts

Re: Migrating from Supabase

#41

Post by ilrwbwrkhv »

dingledork69 wrote: post #40
ilrwbwrkhv wrote: post #13

I also had the same experience with Supabase. Even though it looks like a great product initially, it has a lot or errors and bugs when you are trying to actually build something more robust than a toy app. Local development is a massive pain with random bugs. The response time of the database also varies all over the place. But the most important problem that we faced, was having so much of application logic in the…

I don't use supabase, but am a big postgres fan: > that stuff in unmaintainable Wrong. Version your functions and use something like liquibase to apply migrations.

And handwrite xml? No thanks. Again, if I wanted to do any of this management myself, I wouldn't be using a PaaS.

Re: Migrating from Supabase

#42

Post by kiwicopple »

omeze wrote: post #3

The local development & database migration story is Supabase's biggest weakness. I hate having to do migrations live in prod. The admin dashboard is just so much better than any alternative Postgres tooling that it's been worth using despite that. Takes care of the stuff I'd normally be sweating over when writing migrations like nullable fields / FK constraints / JSON formatting for default fields. Would be great if…

Please don't use the Dashboard to edit your database in production. We're working on Preview Databases which will help enforce this. For now this fits into our Shared Responsibility Model:

https://supabase.com/docs/guides/platform/shared-responsibil...

You are responsible for a workflow that's suitable for your application. Once you get into production, you should be using Migrations for every database change. I have a more thorough response here: https://news.ycombinator.com/item?id=36006018

Re: Migrating from Supabase

#43

Post by crooked-v »

kiwicopple wrote: post #15

hey hn, supabase ceo here the Val Town team were kind enough to share this article with me before they released it. Perhaps you know from previous HN threads that we take customer feedback very seriously. Hearing feedback like this is hard. Clearly the team at Val Town wanted Supabase to be great and we didn’t meet their expectations. For me personally, that hurts. A few quick comments 1. Modifying the database in pr…

I feel like the issue with the Supabase dashboard and database modification is more one of your general approach. You put editing stuff all right up front when at best it should just be an emergency hatch, and the only place to find info on migrations is by going and looking around in the docs.

Re: Migrating from Supabase

#44

Post by Ethan_Mick »

How do people on HN like Row Level Security? Is it a better way to handle multi-tenant in a cloud SaaS app vs `WHERE` clauses in SQL? Worse? Nicer in theory but less maintainable in practice?

fwiw, Prisma has a guide on how to do RLS with it's client. While the original issue[0] remains open they have example code[1] with the client using client extensions[2]. I was going to try it out and see how it felt.

[0]: https://github.com/prisma/prisma/issues/12735

[1]: https://github.com/prisma/prisma-client-extensions/blob/main...

[2]: https://www.prisma.io/docs/concepts/components/prisma-client...

Re: Migrating from Supabase

#46

Post by danielrhodes »

motoxpro wrote: post #21

Great read. Similar to my experience with Hasura. Migrations we’re better there but the row level security was a nightmare. Went to just a custom node backend with prisma and it’s a dream. No more writing tons of json rules and multiple views just to not query the email field. Seems like these types of services are good for basic large scale crud applications, probably why you have Hasura pivoting to enterprise. The…

Had a similar experience with Hasura. They have done some amazing things leveraging Postgres and GraphQL. But there were just too many things that got really questionable. Things like migrations becoming inconsistent with metadata, schema lock in, poor ability to do rate limiting, having to use stored procedures for everything, weird SQL that had performance issues, unexplained row level locking, and so on. Local development was a total mess.

Ultimately we were making architectural decisions to please Hasura, not because it was in the best interests of what or how we were building.

Re: Migrating from Supabase

#47

Post by kiwicopple »

crooked-v wrote: post #43
kiwicopple wrote: post #15

hey hn, supabase ceo here the Val Town team were kind enough to share this article with me before they released it. Perhaps you know from previous HN threads that we take customer feedback very seriously. Hearing feedback like this is hard. Clearly the team at Val Town wanted Supabase to be great and we didn’t meet their expectations. For me personally, that hurts. A few quick comments 1. Modifying the database in pr…

I feel like the issue with the Supabase dashboard and database modification is more one of your general approach. You put editing stuff all right up front when at best it should just be an emergency hatch, and the only place to find info on migrations is by going and looking around in the docs.

yes, I agree. We're working on ways to make the Migration system more prominent in the Dashboard. Preview Databases will help with this too.

> just be an emergency hatch

I would go as far as saying that migrations should still be used beyond the initial development. The Maturity Models linked above include 4 stages: Prototyping, Collaborating, Production, Enterprise. After "Prototyping", everything should be Migrations.

The exception is that you can use the Dashboard for local development. When you run "supabase start", you can access the Dashboard to edit your local database. From there you can run "supabase db diff" to convert your changes into a migration.

Re: Migrating from Supabase

#48

Post by MuffinFlavored »

kiwicopple wrote: post #15

hey hn, supabase ceo here the Val Town team were kind enough to share this article with me before they released it. Perhaps you know from previous HN threads that we take customer feedback very seriously. Hearing feedback like this is hard. Clearly the team at Val Town wanted Supabase to be great and we didn’t meet their expectations. For me personally, that hurts. A few quick comments 1. Modifying the database in pr…

[flagged]

Re: Migrating from Supabase

#49

Post by atonse »

Ethan_Mick wrote: post #44

How do people on HN like Row Level Security? Is it a better way to handle multi-tenant in a cloud SaaS app vs `WHERE` clauses in SQL? Worse? Nicer in theory but less maintainable in practice? fwiw, Prisma has a guide on how to do RLS with it's client. While the original issue[0] remains open they have example code[1] with the client using client extensions[2]. I was going to try it out and see how it felt. [0]: https…

It is highly appealing to have that defense in depth. However, when building a prototype or a product, not having experience in it causes me to worry that we will end up being stuck with a choice where it's very hard to pull ourselves out of.

So instead we've stuck to having that filtering logic in the application side. The main concern is how user auth/etc works in Postgres. (lack of knowledge, not lack of trust).

Because we also have complex filtering like, "let me see all the people in my team if I have this role, but if i'm a public user, only show this person" etc

Re: Migrating from Supabase

#50

Post by crooked-v »

Ethan_Mick wrote: post #44

How do people on HN like Row Level Security? Is it a better way to handle multi-tenant in a cloud SaaS app vs `WHERE` clauses in SQL? Worse? Nicer in theory but less maintainable in practice? fwiw, Prisma has a guide on how to do RLS with it's client. While the original issue[0] remains open they have example code[1] with the client using client extensions[2]. I was going to try it out and see how it felt. [0]: https…

The main issue we've had with it is that it's just plain slow for a lot of use cases, because Postgres will check the security for all rows before filtering on the joins, doing anything with WHERE clauses, doing anything to even tentatively take LIMIT into account, etc.

Imagine a 1-million-row table and a query with `WHERE x=y` that should result in about 100 rows. Postres will do RLS checks on the full 1 million rows before the WHERE clause is involved at all.

Post reply on HN