[billllll]

If you need to built quick, you can get all of this configured out-of-the-box with something like Supabase. If I had to set up all the roles and security myself, I don't know if I'd use it.

The auth is workable - you can authn/z individual users, which is basically what you need with a real backend. Personally though, I think doing auth declaratively is a bit harder than doing it imperatively in code.

If you're just 1 or 2 devs on a fledgling product, I would dare say all your concerns about testing/version control/composability are totally worth it to be able to build fast (and some of it is mitigated with Supabase's setup anyways).

Personally, I think the idea is to eventually migrate to a true backend, without requiring any changes to the schema, and hopefully avoid lock-in.

[ufmace]

I don't know much about Supabase honestly.

On concerns about testing etc. I can see letting automated testing, keeping a clean version control history, good architecture, etc slide at an early stage in the name of building fast. To me, that looks like building stuff in a more mainstream language and framework, but letting yourself be a little bit sloppy about those things. The difference is, the tools you are using don't actively preclude those things, so you keep the option open of adding them in later as needed, as gradually as makes sense. If you're building in one of these limited but all encompassing frameworks like PostgREST, sure you can probably go fast at first, as long as you're coloring within their lines, but as soon as you need something more or need to add some of that other stuff in, you hit a wall, and your only option is to do basically a complete rewrite.

[everforward]

Is there a reason you can't do both? I.e. use PostgREST until you can't anymore (and hopefully get an MVP out of that), then create a backend that runs in parallel and implements whatever PostgREST can't?

It's tech debt that will likely need to be cleaned up at some point, but endpoints could be migrated one at a time, as needed. It seems fairly clean as far as dealing with tech debt goes.