[highwaylights]

Having worked with it quite a bit I'm still not sure I really understand what it is, which sounds like a bizarre sentence but:

It's Postgres, but bundled with some extensions and Postgrest. And a database UI. But hosted and it runs locally also by pulling the separate parts. Running it locally has issues though, so much so that I found it easier to run a docker compose of the separate parts from scratch and at that point just carry that through to a deployment, at which point is there still a reason to use Supabase rather than another hosted Postgres with the extensions?

It's a bit of a confusing product story.

[jonplackett]

I really love supabase. And I’m glad they are getting some funding because I’m terrified they’ll get bought by Amazon or google and completely ruined.

The developer experience is first rate. It’s like they just read my mind and made everything I need really easy.

- Deals with login really nicely

- Databases for data

- Storage for files

- Both of those all nicely working with permissions

- Realtime is v cool

- Great docs

- Great SDK

- Great support peeps

Please never sell out.

[DidYaWipe]

I have no idea where you're finding "great docs" and "great support," because the lack of both of those drove me away from Supabase after having invested quite a bit of time and effort in it.

[whstl]

Which parts did you have a problem with?

Is it the PostgREST part? Are you using it for simple queries, or are you trying to use it for complex business logic?

Asking because PostgREST is great when you use it the way it’s intended but like any tool it will underperform when used in a way it’s not supposed to. It’s a screwdriver that you shouldn’t use to hammer nails.

[DidYaWipe]

I didn't see any purpose to the PostgREST part as a back end to an application, because I'm not going to hard-code queries in my application. My server is going to provide an API that isolates the application from the DB structure.

So no... PostgREST wasn't a factor for me at all.

[steve-chavez]

> My server is going to provide an API that isolates the application from the DB structure.

The same can be achieved with "schema isolation". See https://docs.postgrest.org/en/v12/explanations/schema_isolat....

[DidYaWipe]

Thanks for the reference. I'll take a look.

[whstl]

It seems your opposition to it is philosophical and/or based on assumptions (that one must "hard-code queries in the application"), or limitations of Supabase's Swift library.

I'm sorry you had a bad experience with this kind of tool, but I hope that one day you choose to revisit it.

[DidYaWipe]

"Seems" how? I gave specifics, not assumptions. I already explained WHY an auto-generated HTTP API to your database caters to the hard-coding of queries in the application. And the shortcomings of Supabase's Swift library (or its doc) are neither philosophical nor assumed.

So... what are you talking about?

[mindwok]

The product story is that people want to build apps and naturally find themselves having to handle:

- remote state

- authoritative logic that can't run solely on the user's device because you can't trust it

- authentication

each of which is annoying when you're focused on building the user-facing app experience. Supabase solves all three without you needing to touch any infrastructure. The self-hosting thing just provides insurance that users are not completely locked in to their platform, which is a big concern when you're outsourcing basically your entire backend stack.

[madeofpalk]

it's just a firebase competitor, that's based on postgres and you can run sql against it if you want.

[eddieroger]

It's also implied, and proven by some, that having access to Postgres means you can up and leave Supabase if you want to later. It won't be snap-your-fingers easy, but it's more direct than other hosted SaaS where you can't access your data or the schemas.

[swyx]

that "just" is carrying a lot of weight there

[peab]

exactly this

[DidYaWipe]

Totally agree. I read all kinds of articles and posts and asked for opinions and explanations, to see if I should use Supabase to build a back end for a mobile app.

In the end I jumped into it wholeheartedly, mainly because I wanted a canned solution for authorization and user-confirmation. But soon I came up against obstacles I had easily overcome with plain Deno already, but were seemingly insurmountable with Supabase.

When one basic use-case after another turned out to be almost wholly undocumented and unexplored by the Supabase docs and community, I concluded that Supabase is really only suited for people building Web back-ends that let people browse a database.

As an application back-end, its marquee features don't add value or are basically irrelevant... as far as I can see. The rest of it is incomplete and/or undocumented, with client libraries being an example.

[csomar]

You are not wrong that it’s a postgres + extensions. However, the tech market is very big now and that can sustain these valuations.

[BoorishBears]

Not really a confusing story: it's a PaaS that wants to beat fears of becoming another Parse (https://www.willowtreeapps.com/craft/parse-shutdown-what-it-...)

Realistically 99% of the users would still be screwed if they ever shut down, regardless of if it's open (see: Parse)... but it gives people a some confidence to hear they're building on a platform that they could (strictly in theory) spin up their own instance of should a similar rug pull ever occur

[tough]

They have also been giving back to postgres some of their extra work, and also their real time stuff i think is on erlang?

I agree you might prefer to choose the stack yourself, but for total n00bs and vibe coders supabase is a great start / boilerplate vs say the MEAN stack that was a hit 5y ago