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

91–100 of 136 posts

Re: Migrating from Supabase

#91

Post by replwoacause »

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…

Love this response. The Val Town article was balanced, but your reply to it was too. Well done.

Re: Migrating from Supabase

#93

Post by hnrodey »

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…

Currently only a hobbyist but so far I really enjoy using Supabase and have appreciated the generous free tier. Maybe some day, if I'm lucky, I'll prioritize my projects further and pursue monetization. It would be a great personal development if I needed to graduate to the paid tier.

Anyways, thank you. Supabase isn't perfect but it's pretty damn good.

Re: Migrating from Supabase

#94

Post by steve-chavez »

mfalcao wrote: post #86
jgraettinger1 wrote: post #68

Earlier quoted context omitted.

> Row level security is their "foundational piece", but there is a reason why we moved away from database functions and application logic in database over a decade ago: that stuff in unmaintainable. Funny. In my experience, application-level authorization checks are very error-prone, easy to accidentally omit, and difficult to audit for correctness."Unmaintainable", I suppose. Whereas RLS gives you an understandable…

RLS is great, but it's not that hard to shoot yourself in the foot or miss stuff. E.g.: ALTER TABLE bookmarks ENABLE ROW LEVEL SECURITY; CREATE POLICY bookmarks_owner ON bookmarks USING (owner_id = auth.uid()); CREATE VIEW recent_bookmarks AS SELECT * FROM bookmarks ORDER BY created_at DESC LIMIT 5; The above may look fine at first glance, but recent_bookmarks actually bypasses RLS.

For that there's security invoker now:

  CREATE VIEW recent_bookmarks WITH (security_invoker=true) AS 
  SELECT * FROM bookmarks ORDER BY created_at DESC LIMIT 5;
Point taken though, it's not the default behavior.

Re: Migrating from Supabase

#95

Post by plugin-baby »

esafak wrote: post #70
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…

I use a database that supports unlimited databases, tables, and views. Makes it easy to separate tenants.

Is it Postgres? Schema-per-tenant + table inheritance?

Re: Migrating from Supabase

#96

Post by paulryanrogers »

aeyes wrote: post #71
kiwicopple wrote: post #19

Earlier quoted context omitted.

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

Possibly MVCC keeping a snapshot so the whole dump is consistent.

Re: Migrating from Supabase

#98

Post by mfalcao »

steve-chavez wrote: post #94
mfalcao wrote: post #86

Earlier quoted context omitted.

RLS is great, but it's not that hard to shoot yourself in the foot or miss stuff. E.g.: ALTER TABLE bookmarks ENABLE ROW LEVEL SECURITY; CREATE POLICY bookmarks_owner ON bookmarks USING (owner_id = auth.uid()); CREATE VIEW recent_bookmarks AS SELECT * FROM bookmarks ORDER BY created_at DESC LIMIT 5; The above may look fine at first glance, but recent_bookmarks actually bypasses RLS.

For that there's security invoker now: CREATE VIEW recent_bookmarks WITH (security_invoker=true) AS SELECT * FROM bookmarks ORDER BY created_at DESC LIMIT 5; Point taken though, it's not the default behavior.

Indeed - one of the great changes in v15. (for any folks on previous versions, you need to change the view owner to a non-superuser role without the bypassrls attribute).

Thanks for all your work on PostgREST, Steve! Do you think we'll see relational inserts in the near future, or is that still a bit down the road?

Re: Migrating from Supabase

#99

Post by crooked-v »

steve-chavez wrote: post #78
crooked-v wrote: post #50

Earlier quoted context omitted.

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…

Try it with RLS policies that have any plain JOINs in them to reference other tables and you'll see execution times balloon massively (as in, orders of magnitude worse) for a lot of simple use cases, because it's then doing the RLS checks against every involved table to determine if your original RLS check is allowed to use them. The only way around that if you have multiple tables involved in determining access is to use cached subqueries with SECURITY DEFINER functions that aren't subject to the recursive RLS checking.
Post reply on HN