let me have another run at it:

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

Sorry, confused by the wording: what does 'spinning up' mean here?

Configure and begin running

You're suggesting a hosted Postgres offering isn't "as portable" as a very standard solution?

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.

Is having your frontend hook directly into to your database without a backend a standard? I almost exclusively saw it in locked in BaaS platforms over the years (like Firebase)

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

I'm guessing a "managed postgREST" would look like a docker container deployed to AWS App Runner or Google Cloud Run with the standard Postgres RDS hocked up to it.

Better step away from your keyboard then, until you start to use something and getting locked in.

Point is that if you need to be free, the barrier is lowER.