I&#x27;m the Fred mentioned in the quoted text. As mentioned by 
FLGMwt, Mnesia being a 90s database was an offhand remark done at a workshop in a discussion doing a break.<p>The reasons I considered it a DB of the 90s is that back then, it could have been state of the art, but by today&#x27;s standards, under its current form, it makes sense to be used mostly on fixed cluster sizes with reliable networks and a fairly stable topology.<p>Any fancier cases and you start requiring to dive into the internals when it comes to coming back up from failures, partitions, requiring repairs, and so on. The DB has 3 standard backends: all in RAM, all on Disk (with a 2GB limit), or as a log-copy (infinite disk size, but also bound by memory size).<p>That ends up leaving you with a DB that has a need for its whole dataset to fit in memory, supports distributed transactions but can&#x27;t deal with network failures well out of the box (you need something like <a href="https:&#x2F;&#x2F;github.com&#x2F;uwiger&#x2F;unsplit" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;uwiger&#x2F;unsplit</a>)<p>Mnesia gaining new backends (Klarna is currently open-sourcing code for an experimental postgres backend and are using a leveldb one) would fix a lot of issues as a single-node DB, but another overhaul would be required for the rest.<p>The problem I see is that it was a very cool database back then, but it started lagging behind for a long while and now it has to play a catch-up game. Its model and Erlang interface is still extremely nice and I wish it made more sense to use in production without committing to learning its internals in case of troubles.