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?
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.
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.
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.
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.
"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.
You keep saying “this does X which is bad” while at the same time saying “if it doesn’t do X it is useless”.
To me this is a 100% philosophical opposition.
People find this tech useful. You might prefer writing your own backend. Claiming it doesn’t save time for people who use it to save time however doesn’t make much sense, does it?
> And the shortcomings of Supabase's Swift library (or its doc) are neither philosophical nor assumed.
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.
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.
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.
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
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
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.