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

71–80 of 136 posts

Re: Migrating from Supabase

#71

Post by aeyes »

kiwicopple wrote: post #19
crooked-v wrote: post #14

Earlier quoted context omitted.

Supabase daily backups just use pg_dump. If their database was going offline, then something else was broken.

(supabase ceo) To give context, Val Town have a particularly write-heavy setup, storing a lot of json strings. The nightly backups were causing write-contention, even at their relatively small size. We didn’t detect errors because they were application-level. We should have moved them to PITR as soon as they mentioned it since the timing was so obviously coinciding with backups. We’re investigating moving everyone to…

how does a backup cause write contention? are you backing up to the same disk?

also why are backups using pg_dump? that’s not a backup.

Re: Migrating from Supabase

#72

Post by kiwicopple »

neximo64 wrote: post #66

Can someone explain a bit better what the issues are. What exactly are the issues with migration if you use an SQL script to do the migration instead of the supabase interface?

That's definitely our recommendation beyond prototyping. I shared more thoughts here: https://news.ycombinator.com/item?id=36006754

For developers who have worked with databases before, SQL migrations might be obvious. But for many of our audience it's not. We'll adapt the interface to make this pattern more front-and-center. We also need to improve our CLI to catch up with other migrations tools because a lot of our audience haven't used established tools before (flyway, sqitch, alembic, etc)

Re: Migrating from Supabase

#73

Post by t1mmen »

I hadn’t touched SQL for almost 7 years, but dipped my toes back in to build a PoC using Supabase. Despite some initial pains around RLS, I’ve grown to love it.

Sure, Supabase has some awkward quirks and issue, and author has some good points. But when it works like it should, it’s pretty awesome. I think of it as a powerful wrapper around solid services that make for great DX, in _most_ cases.

If Supabase could provide a great way to handle migrations and RLS, that’d be the biggest improvement to most people’s workflows, I’d bet.

I really wish I could just define my scheme, tables, functions, triggers, policies etc as typescript, then have migrations generated from that.

Re: Migrating from Supabase

#74

Post by robbiep »

MuffinFlavored wrote: post #48
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]

I cannot be the only person here (are there any people left?) that wishes that the comments section does not evolve to LLM summaries of articles.

Re: Migrating from Supabase

#75

Post by jgraettinger1 »

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…

I'm having a hard time relating to this comment given our own experience.

We use RLS extensively with PostgREST implementing much of our API. It _absolutely_ uses WHERE clauses and those are evaluated / indexes consulted before RLS is applied. Anything else would be madness.

Re: Migrating from Supabase

#76

Post by another_story »

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…

Could you be more specific what is difficult about local development? I've used it locally and had little difficulty.

Re: Migrating from Supabase

#77

Post by jgraettinger1 »

crooked-v wrote: post #64
kiwicopple wrote: post #63

Earlier quoted context omitted.

You certainly wouldn't want to inject 80K UUIDs. I'm not sure I understand the structure you're using but if you want to send me some details (email is in my profile) I'd like to dig into it As an aside, this is a good read on the topic: https://cazzer.medium.com/designing-the-most-performant-row-...

At its core it's a pretty simple multi-tenancy arrangement. Think something like this: tenants (id, updated_at) tenants_users (id, updated_at, tenant_id, user_id) products (id, updated_at, name, tenant_id) product_variants (id, updated_at, product_id, name) One of the tenants views a page that does a simple `SELECT * FROM products ORDER BY updated_at LIMIT 100`. The RLS checks have to reference `products` -> `tenants…

Do you have an index on `updated_at` ?

Re: Migrating from Supabase

#78

Post by steve-chavez »

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…

> 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.

Note that the above only happens for non-inlinable[1] functions used inside RLS policies.

Going from what you mentioned below, it seems your main problem are SECURITY DEFINER functions, which aren't inlinable.

It's possible to avoid using SECURITY DEFINER, but that's highly application-specific.

[1]:https://wiki.postgresql.org/wiki/Inlining_of_SQL_functions#I...

Re: Migrating from Supabase

#79

Post by MuffinFlavored »

robbiep wrote: post #74
MuffinFlavored wrote: post #48

Earlier quoted context omitted.

[flagged]

I cannot be the only person here (are there any people left?) that wishes that the comments section does not evolve to LLM summaries of articles.

For me it's the opposite. You've got the CEO speaking corporate platitudes trying to defend himself in the comments by removing focus on the actual issues at hand. LLM helped summarize the issues at hand.
Post reply on HN