Do not build out your MVP on supabase. If you need to scale and want a MSP do it after the MVP. Detangling the lock in is not fun.
Everything offered by supabase is easily found elsewhere without the MSP lock in.
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: I'm NOT a Supabase employee, just a happy user.
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 out there, which confirms the pain the parent comment is describing.
Yes you get a good UI with Supabase, and even much of that can be hosted yourself.
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.
> 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.
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.
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
Point is that if you need to be free, the barrier is lowER.
On an architectural level, it is also terrifying to have your database exposed to the public internet just hidden behind authentication and RLS policies (which are much harder to reason about for most developers, and for which there is very immature tooling, a recipe for disaster).
Plus the local dev experience leaves a lot to be desired. We spent days trying to get file uploads working only to find that the issue was with local Supabase, and we had to create a remote Supabase database just to upload files successfully. But then we can't "reset" the database to run migrations.
The product is definitely much less smooth to develop on and I've had to provide dozens of hours of free client consulting work to untangle my recommendation of Supabase (didn't feel right to charge them to fix a product choice that I recommended to them).
Right now I'm in a strong "never again" view on this set of technologies. At least not for a long time until the tooling improves.
But it seems like there are some happy customers. So would love to hear a counterpoint of how they overcame all the issues we've faced:
- 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.
- Reliance on RLS for a public service seems risky because RLS quickly gets harder to maintain as you have to get more complex policies in place without much tooling to help you.
- how about the fact that some of your most important code, the RLS policies code, is hard to unit test with today's tooling? And they recommend pgTAP, which, who knows how big this community is?
That combination seems highly risky to me.
Our best bet right now has been to just install prisma and implement more traditional filtering on top of RLS, and just not rely at all on client side connections to postgres. So in a nutshell, moving away from Supabase specific architecture to more traditional architecture. The real "It's just postgres"
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!
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.
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:
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.
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 :)
disclaimer - Supabase employee
Not in my experience. The documentation and infra is just not there to make it easy to use an external postgres db.
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)
That said it feels like every other week there's an update that breaks the self hosted compose, looking through the GitHub issue tracker shows a few issues where the suggestion is "oh yeah the latest X image doesn't work, regress the version to get it running"
I really like supabase, but stability on the self hosted images is my biggest gripe with it currently.
If you target Postgres, just about any Postgres instance works the moment you enter a connection URL.
You can hop from one managed Postgres offering to another in 10 minutes and lose no functionality. Everything from auth to programming (and even RLS implemented in the query space) will work instantly: no additional software needed.
Are you claiming that's the case with Supabase and its JWT auth/RLS entanglement?