Earlier quoted context omitted.
Kinda sounds like "client side connections to postgres" was the poor decision at root of your security concerns, not the choice of provider
Client side connections and RLS are the Supabase blessed path in the getting started docs
We are moving to General Availability
51–60 of 106 posts
Re: We are moving to General Availability
#52Earlier quoted context omitted.
Kinda sounds like "client side connections to postgres" was the poor decision at root of your security concerns, not the choice of provider
Client side connections and RLS are the Supabase blessed path in the getting started docs
Re: We are moving to General Availability
#53Re: We are moving to General Availability
#54Re: We are moving to General Availability
#55Congrats 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…
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.
Re: We are moving to General Availability
#56Earlier quoted context omitted.
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...
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.
Re: We are moving to General Availability
#57Earlier 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.
> 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,
No, not if you don't use those other services. If you _do_ decide to use another service, then yes, you need to spin it up to leave (or migrate to something else). Hence my comment: this is no different than running, say, Rails on a managed service.
Re: We are moving to General Availability
#58Earlier quoted context omitted.
> 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.
https://supabase.com/blog/studio-introducing-assistant#user-...
and you can expect to see another related launch this week with some more in-depth tooling:
Re: We are moving to General Availability
#59Congrats 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…
> 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
Do you guys spin up individual Postgres instances for people or use some multi tenant approach?
Re: We are moving to General Availability
#60Happy 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