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.