Olric: Distributed, embeddable data structures in Go

One, it stores Erlang terms. The consequence is that you need no data conversion when you want to store data persistently on disk. You just save whatever term you have.

Two, it provides Key/Value lookup at memory read speeds. It also does so across Erlang processes, so you don't have to call into another process to grab data in most cases. This was originally a main design constraint. You need it for low latency operation, and the only way to avoid a disk read is to keep things in memory. Nowadays, since we have fast disks with no seek-time, it matters less. But when Mnesia was built, we didn't have that luxury. Note that many other systems run in separate processes (memcached, redis, ...) which incurs a context switch and data transfer across a OS process boundary. When the K/V store is in the same memory space things are much faster.

Three, it is an excellent tool for rapid prototyping, and early development work. You can easily buy two terabytes of memory nowadays. Hence, scaling memory is relatively easy (save the time it takes to make that data hot in memory). This means your first million customers are easily served from memory, and it'll take a while before you reach a million customers. Mnesia also allows you to plug in other storage backends, so you can eventually move to a more traditional setup later.

Four, mnesia does provide query capability through a query planner. So for the occasional larger query, there are tools built-in which solves your problem in a very small amount of code.

I do wish plasma wasn't dead/dying though. There is a huge gap in the (extremely crowded) key-value store space for zero-copy shared memory IPC. I assume it doesn't get built because it's not very "cloud native," but such a thing would be undeniably useful.