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

121–130 of 136 posts

Re: Migrating from Supabase

#121

Post by tmcw »

xwowsersx wrote: post #90

> we just wanted a database. ... > Render Preview Environments are amazing: they spin up an entire clone of our whole stack — frontend remix server, node api server, deno evaluation server, and now postgres database — for every pull request. So they wanted more than a database then, no? Are they saying they really just needed a DB and the other stuff was a nice bonus? If they really wanted just a DB, are there not ch…

[op]: Render is a web host, on which we host other applications. They offer a managed Postgres version, which is in my experience pretty similar to Heroku, RDS, or other managed databases.

Maybe the sentence makes that confusing - we're using other stuff on Render, which are basically "web servers" in the Heroku-ish sense, and we're also using their managed database, which is just a database. And it's nice that Render, like some other managed hosting providers, lets you boot up and connect those services.

I guess it's more than a database in some sense because it networks to our web servers and can be booted up in a preview environment, but it is mostly just a database. There are cheaper options that would be more work to wire up in such a convenient way, but the pricing difference between a database on AWS and one on Render is not the highest priority right now.

Re: Migrating from Supabase

#122

Post by tmcw »

igalklebanov wrote: post #117
tmcw wrote: post #17

Earlier quoted context omitted.

Sure! I think Kysely is great too, but went with Drizzle for a few different reasons: Kysely is a little more established than Drizzle, which I think is one of the major reason why it has broader adoption. My bet is that Drizzle is moving really fast, gaining adoption, and might catch up at some point. It's also - in terms of performance - super fast, and nicely layers on top of fast database clients. Some of the dif…

> It's also - in terms of performance - super fast Kysely is also super fast. Your bottleneck will always be database requests. If you're chasing every milli, why node.js? > the extra database drivers being core and developed as part of the main project. Kysely's dialects are dead simple to implement on your own. As evident by all the 3rd party dialects being open-sourced and all the comments from people using Kysely…

Personally I like both projects, as I hope I made clear in the OP - I sense that there's some history and strife here that I'm not clued into as an outsider.

Re: Migrating from Supabase

#123

Post by spiffytech »

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 found RLS challenging to work with when I prototyped an app with it and postgraphile.

I had seemingly-simple authz rules that RLS made challenging to express. I needed some operations honor the user's row access privileges, but with different column SELECT/UPDATE privileges. E.g., a user can only change a value after the backend validates and processes the input, or they shouldn't be allowed to retrieve their password hash.

Expressivity was challenging, but was compounded by security being implicit. I couldn't look at any given spot in my code and confirm what data it's allowed to access - that depends on the privileges of the current DB connection. Once you mix in connections with cross-user privileges, that's a risky situation to try to secure.

Re: Migrating from Supabase

#124

Post by t1mmen »

jononomo wrote: post #112
t1mmen wrote: post #73

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 prov…

> I really wish I could just define my scheme, tables, functions, triggers, policies etc as typescript, then have migrations generated from that. I've recently been using the Django ORM, which automatically generates migrations, and it is absolutely awesome.

Thanks for the tip, that sounds exactly what I’m looking for (outside of node ecosystem, but I’ll take what I can get)

Re: Migrating from Supabase

#125

Post by igalklebanov »

tmcw wrote: post #122
igalklebanov wrote: post #117

Earlier quoted context omitted.

> It's also - in terms of performance - super fast Kysely is also super fast. Your bottleneck will always be database requests. If you're chasing every milli, why node.js? > the extra database drivers being core and developed as part of the main project. Kysely's dialects are dead simple to implement on your own. As evident by all the 3rd party dialects being open-sourced and all the comments from people using Kysely…

Personally I like both projects, as I hope I made clear in the OP - I sense that there's some history and strife here that I'm not clued into as an outsider.

> Personally I like both projects, as I hope I made clear in the OP

You did, but it generally sounded like Kysely doesn't have a bunch of things, when in fact it does.

A more balanced comment would've suggested both projects have X, but I like Y's implementation better.

So I jumped in, to inform and give my 2 cents. :)

> I sense that there's some history and strife here that I'm not clued into as an outsider.

There's none of that really. :)

Re: Migrating from Supabase

#126

Post by tacker2000 »

I mean i get that using such a service will somewhat speed up the initial “time to release”, but i still dont understand why i would use such a layer on top of a normal DB instead of just using a programming framework with an ORM or even a direct DB connection.

After some time you just run into limitations and have to maneuver the around weird stuff that somehow the platform has imposed on you, things that just wont happen if you just use the vanilla DB.

The passage in the article about the DB going offline during a backup every day at midnight is just insane to be honest.

Also these services typically cost much more than just self hosting a DB.

And why the hell would i ever put any amount of substantial business logic in the DB itself? Yes there are maybe speed benefits but in most cases the added burden of doing this is not necessary, compared with using actual code.

Re: Migrating from Supabase

#127

Post by xwowsersx »

tmcw wrote: post #121
xwowsersx wrote: post #90

> we just wanted a database. ... > Render Preview Environments are amazing: they spin up an entire clone of our whole stack — frontend remix server, node api server, deno evaluation server, and now postgres database — for every pull request. So they wanted more than a database then, no? Are they saying they really just needed a DB and the other stuff was a nice bonus? If they really wanted just a DB, are there not ch…

[op]: Render is a web host, on which we host other applications. They offer a managed Postgres version, which is in my experience pretty similar to Heroku, RDS, or other managed databases. Maybe the sentence makes that confusing - we're using other stuff on Render, which are basically "web servers" in the Heroku-ish sense, and we're also using their managed database, which is just a database. And it's nice that Rende…

Thanks, that does clear it up. I was missing the context about Render's full offering. Makes sense re the current priority; I can see many situations or phases of a company where using Render could make a lot of sense even if there are cheaper way to get a PG database.

Re: Migrating from Supabase

#128

Post by iowahansen »

Real-world "things we ran into" stories like this are super helpful when choosing a service or technology.

Unfortunately, I have a similar experience with Firebase, where I wish I would have known that:

* Don't like the text of your Firebase Auth SMS verification message that we send on your behalf -> tough luck

* Your app name is longer than 15 characters? We are not going to include that hash in your Firebase Auth SMS message that is required by Android to perform an automatic login.

* Global Firebase Auth SMS pricing does not work you economically? Welcome to implement the whole thing yourself anyways.

* Dealing with development environments is flakey, as Firebase's emulators work 98% similar to production, but you will regularly hit things that are different.

* You can't completely automate environment creation/tear down, as not everything is covered by Terraform or Google's own APIs, so you will end up doing manual things in their admin interface.

* Real-time subscriptions in Firestore end up not being worth the tight schema coupling between client and server, as you can't control when the updates fire and you end up with a lot more unintended side effects than what this technology benefits you.

So after a year of workarounds you finally end up deeply understanding the trade-offs involved in Firebase and make the decision that its downsides exceed its out of the box benefits. :(

Re: Migrating from Supabase

#129

Post by dshukertjr »

brylie wrote: post #119
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…

Hey, I’d love to try out Supabase as a backend for Flutter apps. However, the docs and scaffold code, like authentication flows, are a bit lacking for Flutter. What are the plans for improving the Flutter-related documentation and packages? Are there any good first issues on GitHub related to Supabase + Flutter?

Hi there, Supabase Flutter SDK maintainer here. Appreciate the feedback here. Specifically what auth flow is under documented you think?

Re: Migrating from Supabase

#130

Post by kebsup »

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…

Hi, I've recently gave supabase a shot to as an alternative to firebase because I needed SQL. One thing that I've struggled with from the start is that supabase seems to ignore backends completely.

I don't want to use supabase edge functions, since I want to keep it simple with a single express backend and don't want to be vendor-locked.

In firebase, the Admin SDK https://firebase.google.com/docs/admin/setup solves this, but seems to be missing in supabase. For example, for a simple JWT verification, I had to go to old github issues, rather than finding the answer in the docs. https://github.com/supabase/supabase/issues/491#issuecomment...

Post reply on HN