"[A long-running, traditional server process] awaiting requests... is not a short-living process."

That's an irrelevant tautology; the question was why you believe a long-running traditional server process is necessary.

At the end of the day, most web servers are about serving requests. A short lived function model fits that more closely.

So you think starting up a whole process, establishing connections to a db and serving the request would have any sort of acceptable latency and/or throughput? At that point, you could write your server in bash as well.. also, I think it would be ridiculously expensive.

Lambda is great for seldom run functions, like running some analysis/conversion on user uploaded profile pictures or the like.

Lambda containers serve multiple requests. You just write the code as if you were handling a single request. And on the contrary, Lambda latency is worst when you have spiky traffic patterns (such as for a seldom run function). Of course, if you can tolerate the cold start latency overhead, Lambda is also a cost effective solution for those seldom run functions.

Also, specifically for Aurora, Lambda supports transparent connection pooling. It is just no longer a concern of your application code.

Disclaimer: I work on serverless services at AWS. I’m definitely biased :)

Thanks for the correction! My point was not at all to “bash” Lambdas, just to point out the (in my opinion) incorrectness of grand(grand?)parent’s comment.

Though I suppose Lambdas don’t use separate traditional OS processes to serve requests, do they?

To answer your (intended-to-be-rhetorical) question: yes! NextJS webapps deployed to Vercel / AWS lambdas have excellent performance characteristics.