no regrets. the ecosystem has been pretty solid for everything we've wanted to do. Stability/performance has been very good.
also: if you're looking for a high profile startup using elixir, supabase is almost entirely elixir and discord uses it for some critical parts.
During the pandemic, our elixir app sent/received 45 million text messages, helped schedule 1.5 million vaccination appointments, and a few million COVID testing appointments.
It all scaled and performed flawlessly. Any bugs were our fault :-)
All not on the list.
There's also the legendary bleacherreport abandoning elixir and totally shooting themselves in the foot.
Several fintech companies moved off - brex, ramp. I think for brex they were told by VCs to hire XYZ CTO and the CTO couldn't elixir. Hilariously I ran into ramp people totally in the wild who complained that "they couldn't find elixir devs". I told them "you just randomly ran into one". I think their hiring processes were likely broken, but what's new in silly valley?
In my very opinionated opinion, it's actually reasonably uncommon for me to read a story of someone leaving a stack and not classifying it as one of the things I listed above. Of the cases I would consider "legitimate", it's usually a performance issue; some languages and runtimes are just intrinsically slower than others, or at least, intrinsically slower without an unrealistic amount of effort. (Elixir would be middling here. BEAM is kind of between the dynamic scripting languages and the compiled languages. The interpreter is simple enough that it can run much faster than the dynamic scripting languages but it would be completely unacceptable performance for any compiled language. You can run out of performance in BEAM, but it does take a system that needs performance and some growth to get there.) The rest are probably complexity explosion of some framework, and this is almost always a UI framework problem.
We mostly used mnesia as a replicated key-value store, but we got a lot of value from having the data and the business logic colocated. Other nodes would send logical operations to processes on the mnesia node and those processes could run each operation one at a time on the data. Any concurrent logical requests for a given piece of data were implicitly serialized by the process mailbox. But almost all of our data was easy to shard, no high volume operations needed to address multiple tables.
We heard a lot of things about mnesia scalability limits that just didn't match up with our experience; so I don't know what other people were doing, but you can get a glimpse of what we were doing in the Rick Reed talks at Erlang Factory.
Mnesia doesn't (or didn't) include a good way to handle when two mnesia nodes sharing a schema disconnect and reconnect. We mostly solved that by ensuring our network was stable enough that that rarely happened. If your network is not stable, you will have a bad time with distributed Erlang in general, and Mnesia in specific.
If I were building Twitch but smaller, and on the BEAM, I would absolutely put account databases in Mnesia; but messages and media would probably live as files. I wouldn't tend to put those into a SQL database on a server either though.
Although it would be great if it spoke SQL, maybe one day it will: https://github.com/elixir-dbvisor/sql since we can already pass it and get the AST.