When is Oban preferred over AWS Lambda?

Personally, I’d never choose aws lambda.

A serverless approach doesn’t seem to leverage any of the strong points of BEAM, and waiting the startup time of BEAM on such environment is not worth it. So if you’re going serverless, most probably you’re not using elixir.

Oban on the other side can handle running multiple instances of the same service, even if you don’t run your elixir app as a beam cluster.

Just because of that, if your codebase is mainly in elixir, i don’t see any good reasons to use aws lambda.
If you’re dealing with multiple languages or elixir is not your main language, there might be reasons to consider using aws lambda.

edit: and it’s good to keep in mind that oban is not the only way to do background work in elixir. it’s a good one, but there stuff you can handle easily with supervised tasks and other approaches.

AWS Lambda is mostly aimed at compiled languages whose binaries start ultra-fast (2ms to 30ms) – think Rust, OCaml, Go, Zig, Nim.

Erlang/Elixir have relatively long startup time – 0.5 to 1.0 seconds – and they are a terrible fit for serverless platforms.

Unless one wants to experiment with Firefly GitHub - GetFirefly/firefly: An alternative BEAM implementation, designed for WebAssembly · GitHub

We have lots of lambdas in python. Startup time is no problem if you keep the lambdas warm.

Don’t they get frozen after a bit of inactivity? Maybe that’s what you mean by keeping them warm – you got a background service that pings them every now and then?

Yeah, you use a timer and ping them every once in a while, it should not be expensive if you plan it well.

That said, AFAIK python has a better startup time than elixir and I agree with you that if you’re using a lot of serverless functions elixir isn’t the best choice.

Big thing for me is simplicity. One thing I love with elixir is that you can have pretty much everything in your app + PostgreSQL. I use to be much more into microservices and stuff but in the end you just end up spending so much on connecting everything and development becomes so much more complex.

see here: Operating Lambda: Performance optimization – Part 1 | AWS Compute Blog

Geez, that’s very long. Is it said anywhere exactly how long do they wait until they “freeze” a warmed-up lambda?

A lot of fine thought here, me personally it’s because:

1. Simplicity, if you only care about doing basic async processing, elixir / BEAM it self already has tools to do it easily, such as supervised task or process.
2. For more durable / consistent job, using a dedicated job queue library give better control over retry behavior, uniqueness consideration, worker, etc. over using AWS Lambda + SQS
3. Avoid vendor lock-in.
4. Transactional outbox pattern (sending message as part of transaction) could be performed more safely on Oban (rather to SQS directly), because Oban is based on postgres, it could get transactional guarantee of postgres.

That being said, i would probably go with AWS lambda if work i do is:

1. Pretty complex / hard to do in elixir, enough to justify writing it on another language.
2. Needing good integration to the rest of AWS ecosystem, such like: Cognito Post-sign up integration, API gateway integration, etc.