> However, the aim of this stack is simplicity, but it is incompatible with serverless products, which I now vastly prefer for ease of use and lower effort- traits
The issue with this statement is that you're comparing things that works on different layers. PostgREST is for someone to host the database without any backend, serverless as you describe it is just a SaaS service you use. If there was a SaaS that exposed PostgREST as a service, it'll be a similar experience.
So unless you're comparing running a serverless platform yourself with running PostgREST yourself (which would be pretty obvious which one is the easiest), I feel like you missed with your argument here.
I’m talking about the stack as a whole, which happens to be built on PostgREST.
The OP’s goal was to simplify their stack, which they did do. However, they cannot run this stack without managing a database, as the database and REST API are run in the same container. My point is that another way to lower a project’s required effort is to offload database management.
Sure, OP now only has two layers in the stack instead of three. But now they are locked into managing the database entirely, including updates, backups, and scaling.
Okay, I think this idea has legs. There's a proven market for Serverless offerings, so how would people react to a SaaS product that:
a) Did database management for you, a la Amazon RDS (perhaps later supporting BYO Cloud Database)
b) Provided a software programming layer that simplified coding, versioning, deployment and rollbacks of Stored Procedures
c) Perhaps provided a language environment that lets you program with an SDK in your language of choice, and then "lifted" that into stored procedures
My first thought when faced with this is, how do I do application monitoring, logging, exception handling, paging? Perhaps this is a solved problem, but I'm curious.
The issue with this statement is that you're comparing things that works on different layers. PostgREST is for someone to host the database without any backend, serverless as you describe it is just a SaaS service you use. If there was a SaaS that exposed PostgREST as a service, it'll be a similar experience.
So unless you're comparing running a serverless platform yourself with running PostgREST yourself (which would be pretty obvious which one is the easiest), I feel like you missed with your argument here.