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

51–60 of 136 posts

Re: Migrating from Supabase

#51

Post by notyograndma »

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…

Hi - We're an analytics solution for a specific vertical, so this is probably not appropriate for everyone but - what we did was create partitioned data tables that are named using a hash of the user UUID and other context to create the partition table name upon provisioning data tables for the user. The parent table is never accessed directly. We're using Supabase, but we don't use Supabase's libraries to operate this.

Re: Migrating from Supabase

#52

Post by kdrag0n »

Honestly, I want to like Supabase but a lot of this resonates with me even for a fairly small project. I also ended up with 3 user tables due to RLS limitations: auth users, public user profile info, and private user info (e.g. Stripe customer IDs). PostgREST's limitations also had me going back to an API server architecture because I definitely didn't want to write logic in database functions.

The only reason I haven't migrated yet is because I'd have to rewrite the data layer to use Prisma/Drizzle instead of Supabase's PostgREST client, and considering that this is a side project, the problems aren't quite big enough to justify that.

Re: Migrating from Supabase

#53

Post by bodecker »

(Significantly edited after discussion)

I also had a tough time working w/ an app someone else built on Supabase. We kept bumping up against what felt like "I know feature X exists in postgres, but it's 'coming soon' in Supabase." IIRC the blocker was specific to the trigger/edge function behavior.

However after reflecting more, I don't remember enough to make a detailed case. Perhaps the issue was with our use of the product.

Re: Migrating from Supabase

#54

Post by koromak »

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.

Way less friendly than writing code IMO

Re: Migrating from Supabase

#56

Post by kiwicopple »

crooked-v wrote: post #50
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 row…

With PostgREST you can use the pre-fetch method to solve this: https://postgrest.org/en/stable/references/transactions.html...

You can use that to inject your ACL/permissions into a setting - set_config('permissions', '{"allowed":true}'). Then in your RLS rules you can pluck them out - current_setting('permissions'::jsonb).

This should make your RLS faster than most other options, in theory, because of data co-location

Re: Migrating from Supabase

#57

Post by datavirtue »

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…

"Local development is a massive pain"...that's enough to kill it for me. No need to point out anything else.

Re: Migrating from Supabase

#58

Post by bodecker »

PKop wrote: post #38

Interesting statement here: "We rewrote our data layer to treat the database as a simple persistence layer rather than an application. We eliminated all the triggers, stored procedures, and row-level security rules. That logic lives in the application now." Reminds me of the article and discussion here[0] over whether to put logic in the database or not and to what degree. [0] https://news.ycombinator.com/item?id=356…

Also reminds me of this Martin Fowler post [0]:

"The situation becomes interesting when the vast majority of your data sits in a single logical database. In this case you have two primary issues to consider. One is the choice of programming language: SQL versus your application language. The other is where the code runs, SQL at the database, or in memory.

SQL makes some things easy, but other things more difficult. Some people find SQL easy to work with, others find it horribly cryptic. The teams personal comfort is a big issue here. I would suggest that if you go the route of putting a lot of logic in SQL, don't expect to be portable - use all of your vendors extensions and cheerfully bind yourself to their technology. If you want portability keep logic out of SQL."

[0] https://martinfowler.com/articles/dblogic.html

Re: Migrating from Supabase

#59

Post by kiwicopple »

bodecker wrote: post #53

(Significantly edited after discussion) I also had a tough time working w/ an app someone else built on Supabase. We kept bumping up against what felt like "I know feature X exists in postgres, but it's 'coming soon' in Supabase." IIRC the blocker was specific to the trigger/edge function behavior. However after reflecting more, I don't remember enough to make a detailed case. Perhaps the issue was with our use of th…

(supabase ceo)

> "I know feature X exists in postgres, but it's 'coming soon' in Supabase."

There is no feature that exists in postgres that doesn't already exist in Supabase. In case it's not clear, supabase is just Postgres. We build extensions, we host it for you, and we build tooling around the database. Our Dashboard is one of those tools, but there is always an escape hatch - you can use it like any other postgres database, with all the existing tooling you're most comfortable with.

Re: Migrating from Supabase

#60

Post by refulgentis »

tr3ntg wrote: post #34
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…

Appreciate this well-thought out response. As someone who has built several proof-of-concepts on Supabase (but never going far enough to test its limits), articles by Val Town here and responses like yours all work towards my analysis of the platform for future projects. It's funny that threads like these bring up comments like "Well I use XYZ and it solves all of my problems." As if a one-time mention of a new PaaS…

+1, paradoxically, I’m even more likely to use supabase after this. Really thoughtful
Post reply on HN