Hacker News Reader

Comment by helsontaveras18 | Hacker News Reader

Open question: what are the benefits of replacing Lambda with this new service, if you’re not using any other Supabase functionalities?

Our Lambdas are currently written in Typescript and built with esbuild. We zip them and push to AWS.

View on HN

The largest advantage currently (in my opinion) is with respect to cold starts. Lambda has gotten significantly better over the years, but cold starts are still a concern, largely because it’s difficult to anticipate the level of needed provisioned concurrency needed to mitigate it. Not having to think about that at all would be a large advantage (I’m ignoring Lambda SnapStart since it’s strictly limited to Java at this time).

It’s also the case that there’s just so much historical baggage within Node, mainly with regard to CJS. Developing against Deno at least presents the opportunity for us to move past that and improve DX.

These would boot faster since you don’t have to boot a whole OS, just a V8 VM. Downside is compatibility, your lambdas would have to be largely rewritten (especially if they rely on any other AWS services). It’s also probably more expensive since you’d have to keep a EC2 or something up running this.

Kinda wish Amazon would have an alternative runtime that was more like this. They kinda do with lambda@edge, but that’s only for CloudFront stuff, mostly.

Lambda@Edge is a great solution for the locality problem (CloudFront can just route to the nearest edge function, and despite certain headaches, it works well), but what it doesn’t help to solve is the cold start problem. In a sense Lambda@Edge works against it, as provisioned concurrency is only supported for ‘regular’ Lambda functions.

At a certain level of scale, the cost of spinning of an ALB Fargate task (which could run these servers relatively easily) ends up being relatively negligible. Although that’s certainly not true for every org.

Reply on news.ycombinator.com