Live data from Hacker News

We are moving to General Availability

supabase.com

41–50 of 106 posts

Re: We are moving to General Availability

#41
post #27

Earlier quoted context omitted.

This isn't fair feedback. You have to be more specific about the "lock in". Supabase itself is just managed Postgres and can be self-hosted. The entire point is that everything they offer is open source and easily found elsewhere. I can imagine they fall short in some aspects from that ideal and I would love to know your experience but even with your first sentence this is just a pretty damning write off. Disclaimer:…

People keep writing this, doesn't Supabase rely on spinning up additional services to leave, meaning you can't leave to another managed offering? Off the top of my mind, PostgREST and go-true? https://github.com/supabase/auth - If you use Postgres you're "locked" into Postgres: a technology with a laundry list of providers. If you leave Supabase, you'll lose the fully managed aspect of 99% of the Postgres providers o…

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

Re: We are moving to General Availability

#42
post #6

Earlier quoted context omitted.

I've used it for a couple uni/personal projects to get some experience, and firebase for the same. I'm concerned about getting locked in, what other providers do you recommend who can let me migrate more easily?

You can use supabase simply as a Postgres provider. Supabase is just postgres, and you can choose to use any tool we provide (or not)

I've so far found the most value in authentication, so thank you for a great self hostable product

Re: We are moving to General Availability

#43

Earlier quoted context omitted.

> I'm concerned about getting locked in Supabase is one of the most portable platforms out there. The whole stack is self-hostable and open source. All of the data are contained in Postgres. You're one pg_dump away from being able to switch to a different Postgres host. Or if you're switching to something else entirely, you can export the data to CSVs and take it anywhere. But we're confident you won't want to :) dis…

> Supabase is one of the most portable platforms out there Not in my experience. The documentation and infra is just not there to make it easy to use an external postgres db.

we know of many, many companies using Supabase self-hosted or with an external database.

if you have any problems, feel free to reach out to me directly. We want this to be simple (and you can see that there are non-supabase commentors in this thread who are self-hosting, so it's not just lip service)

Re: We are moving to General Availability

#44
They seem to heavily invest in their social media presence with things like the YouTube channel, but then also use social media indicators (likes/follows/subs/etc) as a measure of success. Seems a little circular.

The plot of Github Stars over Time: Supabase vs. MongoDB seems particularly silly (imo).

Not a hater by the way, I think their YouTube channel is actually pretty good, and I think it will become increasingly common for startups/businesses to have something like this for product/brand awareness, getting users up and running, etc.

I think if the goal of the post was focusing on platform maturation and growth, it might have been better to focus exclusively on the plots of database/users over time, and simply link out to the various social channels.

Overall though still cool to see, and congratulations to the Supabase team!

Re: We are moving to General Availability

#45
post #14

Earlier quoted context omitted.

We're using Supabase for a client project and even three sprints in, we're severely hobbled by having to play with a couple of architectural choices forced on us with Supabase and Supabase Auth. Any of the time savings benefits have been wiped out already just fighting the choices and also the subtle differences between the local dev environment, implementing RLS without good tooling. On an architectural level, it is…

Kinda sounds like "client side connections to postgres" was the poor decision at root of your security concerns, not the choice of provider

But that is the path that Supabase strongly recommends if you use their tech stack.

I fully agree that some of the issues (like poor RLS tooling) doesn't necessarily fall on Supabase's shoulders. But this is the path that Supabase strongly recommends.

So you kind of can't have it both ways and say "Supabase is just Postgres" but then say "this is not our problem, it's postgres", right?

I actually think Supabase is in a GREAT position to actually build some of this missing tooling. They're probably now the single largest beneficiary of more people using RLS.

So I do think they will tackle this problem, it is a smart team. I just think that because of these issues, as a cohesive platform, it definitely doesn't feel fully baked (or "generally available" status) yet.

Re: We are moving to General Availability

#46
post #16
post #14

Earlier quoted context omitted.

We're using Supabase for a client project and even three sprints in, we're severely hobbled by having to play with a couple of architectural choices forced on us with Supabase and Supabase Auth. Any of the time savings benefits have been wiped out already just fighting the choices and also the subtle differences between the local dev environment, implementing RLS without good tooling. On an architectural level, it is…

> how are your security teams ok with exposing your PG server to the internet, relying mainly on RLS? And RLS isn't turned on by default, so full tables are exposed to the public internet by default, behind a rather nice REST API. Tooling is improving constantly and security really is at the top of mind for us. We've got some cool announcements this week that will keep reminding you if you're doing something sketchy!

Good to hear, thanks.

I really am trying to provide constructive criticism (even if my tone is not great because the pain I'm continuing to feel with the platform is still fresh).

I do think you guys are in a great position to actually improve all that tooling around RLS. Tools that can analyze your policies, that can visually map the recursive nature of policies that run, etc.

Re: We are moving to General Availability

#47
Interesting how they posted a self-host guide just a few hours before announcing this. https://www.youtube.com/watch?v=FqiQKRKsfZE Perhaps expecting criticism and preemptively creating a response that shuts people down?

Ultimately I just see the same pattern in Supabase as in many of these "easy scaling" solutions: lock in. I think the future is something like those platforms are offering but we're definitely not there yet. Also it's not like I'm an old person refusing to accept new tech. I'm young and looking to create things but I recognize that these services are (currently) doing the complete opposite of giving me freedom.

Re: We are moving to General Availability

#48
post #16
post #14

Earlier quoted context omitted.

We're using Supabase for a client project and even three sprints in, we're severely hobbled by having to play with a couple of architectural choices forced on us with Supabase and Supabase Auth. Any of the time savings benefits have been wiped out already just fighting the choices and also the subtle differences between the local dev environment, implementing RLS without good tooling. On an architectural level, it is…

> how are your security teams ok with exposing your PG server to the internet, relying mainly on RLS? And RLS isn't turned on by default, so full tables are exposed to the public internet by default, behind a rather nice REST API. Tooling is improving constantly and security really is at the top of mind for us. We've got some cool announcements this week that will keep reminding you if you're doing something sketchy!

An access-simulator where you can check if a user (or anon) has some type of access would be helpful.

Re: We are moving to General Availability

#49

Interesting how they posted a self-host guide just a few hours before announcing this. https://www.youtube.com/watch?v=FqiQKRKsfZE Perhaps expecting criticism and preemptively creating a response that shuts people down? Ultimately I just see the same pattern in Supabase as in many of these "easy scaling" solutions: lock in. I think the future is something like those platforms are offering but we're definitely not the…

the video has been available on our self-hosting docs (https://supabase.com/docs/guides/self-hosting/docker) for months (see comments age). I just noticed that it was "unlisted" instead of "public" when I was making this GA page so I made it public. There isn't anything sinister here

> "easy scaling" solutions: lock in

This has been hashed through in a few comments on this post: Supabase is Postgres. We offer tools on top which you can _optionally_ use. Some people love those tools (especially Postgres maxis). Some people prefer to just use the database with Django/Phoenix/Rails/etc. You choose your own level of comfort.

Re: We are moving to General Availability

#50
post #15

hey hn, supabase ceo here we just announced GA, after ~4 years of beta. for those who don't know: supabase is a postgres hosting company. we also host other open source "backend" tools that make it easy to get started with postgres (tools like PostgREST for auto-generate APIs [0]) we owe a lot to the HN community. you launched us 4 years ago [1], when we were just a few developers. since then HN has been a staple in…

Congrats to the Supabase team! You've all done some impressive work to be proud of.

thanks for the kind words
Post reply on HN