You guys are uncovering another bullet point on my list of why I dislike these things 
sodapopcan
eahanson
It’s true that noreply and noreply! do opposite things, and I agree that it is not an ideal naming system. It partially follows the normal naming conventions in that noreply! will raise if it’s unwrapping a tuple that’s not {:noreply, term()}.
0
spagyther
There is Khepri, Riak and OpenRiak, the Couch family of DB tech, Hypermnesia (not much beyond poc stage), and probably I am missing a few. I think the BEAM is one of the ecosystems with most databases, tbf, what are you missing? I have used Mnesia in prod and yes, it’s a pain, you need to build a lot of boilerplate around it to keep it from corrupting your data for one reason or another, but Riak for example is fairly battle tested and works kind of out-of-the-box.
1
garrison
First of all thank you for replying 
I was hoping there would be some discussion on the topic after I posted, but the conversation went elsewhere.
First of all, I just want to point out that this is not necessarily “my opinion” that I’m arguing here. This point is indisputable: Elixir developers are not using BEAM databases. We’re pretty much all using Ecto with relational databases, particularly Postgres/SQLite. I would imagine Postgres users outnumber Mnesia users by at least a few orders of magnitude in this community. When I said we lacked “proper” databases, the word “proper” was doing a lot of work there.
I would say Riak is a “real” database, but architecturally my understanding is that it’s a clone of Dynamo (the original Dynamo at that, not DDB).
This generation of distributed databases was born out of the early 2000s with BigTable and spread to DynamoDB, Cassandra, HBase, etc. The problem is that it’s now 2025, a full two decades later, and frankly these designs turned out to be a bit of an architectural dead end.
First of all, they partition data across machines with no affordances for atomic transactions across partitions (which were often of a limited size). As a result they offer virtually nonexistent consistency guarantees.
Second, because of the “distributed hash table” approach they fail to offer good support for range queries, which are extremely important for managing relational data. So as a result they also fail to offer a relational model, and it is nearly impossible to implement the relational model on top of them.
Modern “NewSQL” databases or transactional K/V stores (like FoundationDB) offer much better consistency guarantees and are built on top of a range-partitioned storage engine (not hash) so that they can perform range scans and implement the relational model. This tech is over a decade old (Spanner 2012, FDB early 2010s), so we’re not talking bleeding edge here. There is nothing like this on the BEAM to my knowledge, but if there is I would of course love to hear about it.
Finally, Khepri seems cool but as I understand it’s just a replicated (not scalable) K/V store which runs all operations through MultiPaxos (actually Raft). This architecture is maybe okay for the old “distributed lock table” approach (which is actually a terrible idea btw), but it’s not appropriate for a “real” database for two reasons.
First, you still only have one table, so you can’t scale this approach to more than one core. And second, by running the log through MultiPaxos on every write you are eating double or triple round-trip latency to write, so it’s just going to be slow.
FoundationDB for example does not do this - there is not even a two-phase commit in the commit path. It’s a much better design.
4
garrison
To give a direct answer, here’s what I want:
A database which is distributed, replicates data, scales horizontally across cores, is highly available, is range sharded, reshards data automatically, is highly available, has extremely strong consistency guarantees (strict serializability) across the entire keyspace, and runs on the BEAM with a simple native API.
From there, I want APIs which can stream updates to particular keys or ranges of keys with perfect consistency (always in-order, never missing updates).
And then on top of that, I want a relational layer with good Elixir integration and top-tier UX. I want strongly typed records (rows), relational queries, secondary indexes with perfect consistency (always up-to-date), and strongly typed schema migrations. I want to be able to perform live queries and receive updates to the result set as changes come in. I want all of this to scale horizontally.
I think this feature set would be enough to justify leaving Postgres. As far as I am aware there is nothing in the ecosystem that could even be used to build what I’ve described above, let alone provides the features I want.
Frankly we don’t even have anything that matches Postgres, a database which architecturally has not escaped the 20th century.
1
D4no0
There are a few reasons why people don’t use mnesia, some of them:
- Peculiar way to do queries. This can be worked around and I think there are a few libraries that do that in elixir pretty well already. Nonetheless this can never be compared to having a proper DSL like SQL;
- No external tooling. For me this is the most important factor when it comes to databases. Having the ability to open a CLI or GUI to query and inspect the database is critical. I’ve even worked on projects where we had analysts that were querying the database, as that was 100x times more productive than trying to build for them some custom web interfaces;
- Migrations and backups. Databases like postgres offer a variety of tools for migrations and backups. If you were to use something like mnesia, you would have to implement all of this from scratch;
Distributed databases are a very niche field and it’s blown out of proportion on how useful they actually are. What I’ve seen in practice is that 95%+ of projects won’t need a distributed database, ever. There are also things like replicated read-only databases that postgres offers, this strikes a perfect balance for cases where you want distribution, but you don’t want to deal with the horrible experience of making all of that stuff consistent.
2
garrison
I was trying to avoid roasting mnesia because I feel like we’re all aware of the drawbacks, but I was surprised to see you left out what I thought the two biggest problems were:
- Tables are limited to something like 2GB and then have to be partitioned, and once you partition them you lose all consistency guarantees, which is catastrophic. Also aren’t they stored in-memory?
- In the event of a netsplit consistency guarantees are nonexistent, which is again catastrophic. From what I remember this is essentially unrecoverable?
Of course the standard disclaimer applies here: the people who built Mnesia weren’t idiots or anything, it’s just that a) it was a really long time ago and b) they were designing for specialized telcom hardware or whatever, not Phoenix webapps!
I understand why you feel this way, but I disagree very strongly with this viewpoint. Distributed databases are very useful first because they can substantially improve durability and availability, both of which have proven to be very difficult to glue onto existing architectures (see the pain and suffering wrought by Flyio’s HA postgres attempts, for example).
But second, they are useful because Moore’s law ended a while ago and compute has primarily increased in parallel (more cores). We have reached a point where even your phone is almost certainly a distributed system, and so distributed databases must necessarily be the default. The ancient 20th century RDBMS architecture (Postgres) is extremely wasteful on multi-core hardware and spends a ludicrous amount of time dealing with lock contention instead of useful work. I don’t think this is something I need to justify because this is the Elixir community and I think we natively understand the benefits of parallel processing here
But that’s the funny thing, isn’t it. It’s like what Joe Armstrong always used to say about Erlang: all it takes is a few smart people to work out the “distributed” part, and then the rest of us benefit for free!
2
D4no0
No offense, but this is not an argument, more like a troll post I would see on linkedin.
Postgres excels at concurrent access to data, this is what it was built for in the first place. If you are in the search for the next hip technology, then I can understand that, but please don’t use the fact that postgres is mature as a argument to jump the ship. As any other tools, you as a professional need to assess where it fits and where it doesn’t.
Is it though, or it’s about easy to manage concurrency? I see a lot of people using concurrent and parallel interchangeably these days, however by definition concurrent code is not necessarily parallel.
Taking in consideration that distribution, redundancy and consistency is a much bigger and harder problem than concurrency, I am more than positive we are at least 20 years behind, or if we were to look at telecom industry, where these problems were prerequisites to make that industry work, maybe we wouldn’t have to reinvent the wheel everytime. I guess that is not fun because the industry is too old.
Look at the currently used programming languages and how bad they are at dealing with concurrency, transpose that technological gap to distribution and the answer is clear that we are not there yet.
0
garrison
I am sorry to see you stoop to essentially insulting me instead of responding to what I wrote in earnest. Obviously I am well aware that Postgres is capable of concurrency, and indeed even parallelism!
Perhaps you would enjoy reading the first HStore paper, from 2007, and if you remain unconvinced then you could try googling the authors, particularly that “Michael Stonebraker” guy, who sure does seem to know a whole lot about databases!
Of course, a lot has changed since 2007: namely, computers have gone from having 2 cores to 20, SSDs ended up being way cheaper than RAM, and networks got really fast.
2
garrison
I think you are at serious risk of overloading the term “concurrency” here, as it has a special meaning in the context of a database.
The “concurrency” vs “parallelism” dichotomy which I think you’re describing has to do with whether work is performed in parallel or split into pieces and worked on “piece by piece” on a single core. The BEAM is very good at both, as we all know.
Concurrency in the context of databases usually refers to concurrency control, which has to do with how the database manages multiple transactions accessing the same data while giving the illusion of serialized execution (“serializable isolation”).
These meanings are loosely related but not really the same concept.
But I did not mention concurrency (of either kind) in my post, at all, so I’m not sure I understand what you were getting at here.
0