it depends on your load really.
there are background job frameworks in other languages like Oban in Elixir that utilizes postgres.
if scale is low, it's not an issue. but once you have high usage, what typically people do is they move it to a separate database, otherwise you're saturating the resources and it starts impacting the application itself.
at that point, that's not much different from external state stored else where.
also another thing about databases is their ACID transactions can only handle up to certain amount of load.
again, if you don't hit that limit, it's totally fine. once you do, which usually means outages, severe delays, etc, and it'll be a shit show.
disclaimer: I do work at Inngest, but also this is speaking from experience. :)
Which part of BEAM are you talking about?
I know some cases can be solved by it already, but not almost every need.
The fairness of the BEAM scheduler is not the same as multi-tenant fairness.
I'm aware of lcnt in Erlang that helps with contention, but that will have a hit in throughput like any other locks.
The way the BEAM scheduler works you get max runtime per process before it switches over to another, which lets you run potentially millions of concurrent processes without having to worry about 1 taking it over because it was heavier. Your big stuff takes longer, but your response times across the board will remain very consistent.
If you wanted to make it truly fair you could spin up a GenServer per tenant and you would have a max concurrency per tenant of 1, but still all executing equally in parallel without 1 tenant stealing CPU time from the others. Contention is a non-issue. Fairness is built in.
You get the fault tolerance, isolation and observability as a by product too.
Thanks for the note, it's changed to underscore now.
Regarding the "ex" prefix, it's a common pattern for Elixir libraries.
https://github.com/h4cc/awesome-elixir
if scale is low, it's not an issue. but once you have high usage, what typically people do is they move it to a separate database, otherwise you're saturating the resources and it starts impacting the application itself.
at that point, that's not much different from external state stored else where.
also another thing about databases is their ACID transactions can only handle up to certain amount of load. again, if you don't hit that limit, it's totally fine. once you do, which usually means outages, severe delays, etc, and it'll be a shit show.
disclaimer: I do work at Inngest, but also this is speaking from experience. :)