My point is that the advertised separation of frontend and backend using stored procedures in your database can be a huge misfeature - it requires a lot of mana

My point is that the advertised separation of frontend and backend using stored procedures in your database can be a huge misfeature - it requires a lot of management and rigor to maintain a compatible API interface that allows that kind of architecture. Frankly more than I'd expect from a bunch of JavaScript snippets (where you usually don't have a lot of tooling to support you). Relying on stored procedures in a hosted database system also means you cannot write locally reproducible, reasonably hermetic tests. It also (obviously) completely binds you to a single vendor. In short, it has all the drawbacks this architecture had when it was still Oracle database servers and stored procedures in PL/SQL (and/or the equivalent from MS, IBM, ...). It also has similar benefits (no need to manage a separate server, simpler architecture, often simpler to get things done for novices). There are good reasons why that architecture largely lost in the market by now, I'd be very careful to make sure this is a good fit for your problem. But of course only you can be the judge of that.