1. Last I checked (admittedly not recently), Lambda throttles CPU proportionally to memory size, e.g. as I recall a 128MB instance is throttled to 1/8 CPU core, 256MB is 1/4, etc. Workers never throttles.
2. The same code running on Workers will use far less memory than when running on Lambda. In fact, the average Worker uses around 3MB RAM. The difference here is that Lambda is counting the memory for the whole runtime process, e.g. a Node.js process, whereas with Workers the runtime is shared with other tenants and only the pure JavaScript heap usage counts against the memory limit.
So, 128MB goes further with Workers.
That said, obviously some apps need more. At present we don't have a way to increase this limit, but we're working on it.
I wonder if it's feasible to use even less RAM per worker. The pioneers of time-sharing would have considered 3MB per user extravagant. Of course, it practically doesn't matter now, but still, I wonder if it would be feasible to reduce the heap size per isolate by at least one order of magnitude.
1. Last I checked (admittedly not recently), Lambda throttles CPU proportionally to memory size, e.g. as I recall a 128MB instance is throttled to 1/8 CPU core, 256MB is 1/4, etc. Workers never throttles.
2. The same code running on Workers will use far less memory than when running on Lambda. In fact, the average Worker uses around 3MB RAM. The difference here is that Lambda is counting the memory for the whole runtime process, e.g. a Node.js process, whereas with Workers the runtime is shared with other tenants and only the pure JavaScript heap usage counts against the memory limit.
So, 128MB goes further with Workers.
That said, obviously some apps need more. At present we don't have a way to increase this limit, but we're working on it.
(I'm the tech lead for Workers.)