Imagine the database were compiled into the application itself. If you only ever have one http server and one database, it's not an issue. If you run into load issues and need to scale out, things become trickier. Moving the database to its own application (say, mongo or redis or postgres) means that your main application can now reside on one machine while your database(s) can reside on a beefier machine (or just multiple machines).

Likewise, 'stateful' applications keep local state, and 'stateless' applications push everything off to either the client or database. They become fungible commodities- at peak load, you can quickly spin up more and shut them down after. With a 'stateful' application, you need to keep it running as long as the sessions (and maybe background jobs or any other local state) are live, unless you have some trivial means of passing that off to another machine.

Load balancing also means needing sticky sessions (i.e. once a client connects to an application server behind the load balancer, the load balancer needs to be able to keep sending the client to the same server). It's a solved problem, but needing to deal with it at all is a thing.

The web got along just fine with stateful applications for years, and things like websockets mandate a certain amount of statefulness, so there's nothing wrong with using it if you want to... OTOH you might just save yourself a lot of pain and effort if you don't. Right tools for the right jobs and all that.

Most of these things are pretty easy in elixir phoenix... And the tradeoff is that if you are sending gobs of http and also doing a fresh db query each time, it's wasteful and can possibly hurt latency too; phoenix tries to solve that. Conceptually one way you can think of it is that it's just a "smarter (in the feature sense, not necessarily the access-optimized sense) cache layer" in front of your DB.