I also recommend just sticking with Postgres, at least for now.

What would be cool, though, is if there would be an Ecto<->Mnesia adapter at some point, because being completely independent from external services remains very compelling.

Looks like someone already started writing an adapter but it’s not ready for production yet: GitHub - webengineer-max/mnesia_ecto: Ecto adapter for Mnesia · GitHub.

I can wholeheartedly recommend trying to write your own adapter as a weekend project or something - I learned a lot about Ecto’s internals (and appreciated it’s design) by doing so.

Shameless plug: you can look at my experiments at github_ecto or ets_ecto. A bare minimum adapter that does something could be this: lib/ets_ecto.ex (from an early commit in that project)

Yes, one of the downsides:)

• You need to manually handle split-brain situations. There are a few well known tricks to do this with various trade-offs but at then end your application will have to handle it and decide what to do.
• You need to keep all your data in memory. Well, you could use dets but then you have a 2GB restriction on table-size. Also there are new backends for mnesia which may solve this (level db)
• You can use fragmented tables to handle above but your application must set this up and handle the fragments.
• It is prone to get overloaded and handling it in distributed settings is harder than you think.
• Slow start-up times (depending on order nodes are started mnesia may decide to copy entire tables to different nodes, this slows down startup time significantly)
• Upgrading table definitions may be hard in a distributed setting and without stopping access to the database.

All this said. Mnesia is a very battle-tested database, it is just that it requires a fair bit of skill to operate and that you know its limitation. There are some pretty big shops running mnesia as a major part of their infrastructure (Whatsapp, Klarna).

Why would you want to use mnesia?:

• You can’t get a faster database for reads as it runs in the same memory space as your erlang application. Anything else handles reads under 40 micro-seconds?
• No impedance mismatch between erlang code and the database. You read terms straight of memory so no serialization layers and no database traffic
• It has transactions. They are of course more limited than a proper database but not many other NoSQL databases have such good history
• Distribution. Have its own problems of course but it is a distributed database

Mnesia isn’t a replacement for postgresql though, It is not an RDMS and as with any other NoSQL database you must have a use case where it fits.

Just to put my bit in:

I use PostgreSQL for anything and everything that needs to persist.
If postgresql is slow on certain queries that I cannot really make better than I either make a materialized view inside postgresql that updates on occasion, or if I do a ton of tiny little queries per transaction that all are the same (like getting permissions across connections, websockets, etc…) then I use CacheX (with a fallback in it set to querying the database) as it has auto-timeout and removal, janitor process, and far far more, including transactions and shared retrievals (it is built on ETS of course).