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

We are moving to General Availability

supabase.com

Post reply on HN
Print view View original

61–70 of 106 posts

Re: We are moving to General Availability

#61

Post by switchbak »

BoorishBears wrote: post #56
kiwicopple wrote: post #41

Earlier quoted context omitted.

this is no different than running, say, Rails on a managed service. You can take the service and you run it somewhere else: each individual service is wrapped into a docker image which should make it easy. You can use as many or as few of the services as you want - its designed it that way: https://supabase.com/docs/guides/getting-started/architectur...

This just sidesteps what I said? Supabase is most attractive to those without the skills to run an unmanaged service A bespoke solution, even if it's open, doesn't mean it's as portable as a very standard solution. If you want portability, the parent comment was right: don't embed Supabase deeply into your application.

You're suggesting a hosted Postgres offering isn't "as portable" as a very standard solution?

This isn't DynamoDB here, this is about as standard as it gets. I'm failing to find the supposed lock-in being talked about here.

Re: We are moving to General Availability

#62

Post by kiwicopple »

moomoo11 wrote: post #59
kiwicopple wrote: post #39

Earlier quoted context omitted.

> We're pretty satisfied with Supabase as an open source project As an open source company, we'll take that as a mark of success. Thanks for the details, I'll jump into that GH issue with the Edge Functions team after this week

Hi. Do you guys spin up individual Postgres instances for people or use some multi tenant approach?

Yes, it’s a full Postgres database.

Re: We are moving to General Availability

#63

Post by BoorishBears »

switchbak wrote: post #61
BoorishBears wrote: post #56

Earlier quoted context omitted.

This just sidesteps what I said? Supabase is most attractive to those without the skills to run an unmanaged service A bespoke solution, even if it's open, doesn't mean it's as portable as a very standard solution. If you want portability, the parent comment was right: don't embed Supabase deeply into your application.

You're suggesting a hosted Postgres offering isn't "as portable" as a very standard solution? This isn't DynamoDB here, this is about as standard as it gets. I'm failing to find the supposed lock-in being talked about here.

Is having your frontend hook directly into to your database without a backend a standard? I almost exclusively saw it in locked in BaaS platforms over the years (like Firebase)

I've barely even seen PostgREST offered managed: is even one managed Postgres provider with the right combination of PostgREST and go-true to let you move over today?

Edit: I also don't get why this is such a point of contention...

Since when is BaaS not just a trade off between initial velocity and later stage lock-in? The former is not worthless, but like most tools you should understand the tradeoffs involved

Re: We are moving to General Availability

#65

Post by waldrews »

kiwicopple wrote: post #57
BoorishBears wrote: post #56

Earlier quoted context omitted.

This just sidesteps what I said? Supabase is most attractive to those without the skills to run an unmanaged service A bespoke solution, even if it's open, doesn't mean it's as portable as a very standard solution. If you want portability, the parent comment was right: don't embed Supabase deeply into your application.

let me have another run at it: > If you use Postgres you're "locked" into Postgres: a technology with a laundry list of providers. Supabase is just a Postgres platform, and you can use it like that so that you can migrate away to any one of those laundry list. We _also_ provide some tools which are nicely integrated but importantly: they are optional > doesn't Supabase rely on spinning up additional services to leave…

Sorry, confused by the wording: what does 'spinning up' mean here?

Re: We are moving to General Availability

#66

Post by trevoragilbert »

kiwicopple wrote: post #36
trevoragilbert wrote: post #34

Happy Supabase user here, albeit on a tiny app I work on in my spare time. So no comment for larger or more complex orgs. That being said, the Swift documentation could use some love. It’s not terrible but it’s also not great. There have been a number of times when I wanted to do something, ended up reading about it on the Supabase JS documentation, and then thought “well I assume it’s roughly the same in the Swift l…

we just took over official support for swift: https://supabase.com/blog/supabase-swift I'll let Guilherme know. feel free to reach out directly with any specific feedback

Ha, the timing makes it look like you did this in response to my comment. :D Very excited about this!

Re: We are moving to General Availability

#67

Post by williamdclt »

k_vi wrote: post #55
jmeyer2k wrote: post #22

Congrats on the launch! Here's our experience with Supabase at https://automark.io (Next.js + Supabase). - First of all, Supabase let us launch fast which was amazing. Super powerful Postgres features without the pain of self-hosting (or so we thought). - We started out using their hosted product for both our DB, storage, auth, and functions. - Functions have a critical bug that prevent us from using in development s…

Tried Supabase but currently only use their Auth. The server to database latency was very high(few hundred ms) whereas Planetscale DB in the same region gives sub 10ms. Still great option for most projects that can do with these issues.

I struggle to imagine projects that can do with a db latency of several hundred ms? Something fully async maybe, any human interaction would be incredibly slow

Re: We are moving to General Availability

#68

Post by mattjenner »

pastor_bob wrote: post #17

Curious to see how many of those million databases are from free users. Feels like we're living in the golden age of free platform offerings. Wonder when the shoe will drop.

I am happily using the free tier to help launch my startup. It is invaluable to me. I am a big fan of it, and have no regrets with this decision (only 9 months in). I admire what I am allowed to have for the low price of 'free now, pay when you need to'.

Re: We are moving to General Availability

#69

Post by szundi »

BoorishBears wrote: post #56
kiwicopple wrote: post #41

Earlier quoted context omitted.

this is no different than running, say, Rails on a managed service. You can take the service and you run it somewhere else: each individual service is wrapped into a docker image which should make it easy. You can use as many or as few of the services as you want - its designed it that way: https://supabase.com/docs/guides/getting-started/architectur...

This just sidesteps what I said? Supabase is most attractive to those without the skills to run an unmanaged service A bespoke solution, even if it's open, doesn't mean it's as portable as a very standard solution. If you want portability, the parent comment was right: don't embed Supabase deeply into your application.

Better step away from your keyboard then, until you start to use something and getting locked in.

Point is that if you need to be free, the barrier is lowER.

Re: We are moving to General Availability

#70

Post by davetron5000 »

I built a toy app using this, with a front-end only app and postgrest + RBS. The app was seriously two forms behind a login. It was a huge pain.

RBS is "insecure by default" meaning if you don't set it up right, all users can access all data. And, because it's SQL, it's really easy to write a valid and successful configuration that doesn't work. You have to test it. And for views, you have to do some real heroics to get them to respect RBS.

PostGREST is very very basic and far less powerful than just writing SQL. I found it pretty frustrating to use, knowing that SQL would be far simpler.

Yes, I know that I could make a direct SQL connection to the database, but at that point, it would've been easier to put a Rails app on Heroku and use their offering, which is far more mature.

The Supabase dev environment was pretty slick and worked well, though I had to docker implode a couple times.

I wish them luck, but I could not figure out what the use case was for their product, given that Heroku has an awesome managed Postgres and RDS is there if you have more knowledge and want more controls. I don't see how you could make a complex app that is front-end only with Supabase as your entire back-end.

Post reply on HN