I’ll turn this question on its head: what sort of features, functionality, and so on are you envisioning you can ONLY get with an Elixir database?

This is the third time this has come up in this thread and I dodged the question the last two times so I may as well answer it properly this time. But I will first reiterate that I am not trying to claim Elixir is somehow the best language in which to implement a database. Rather, I wanted to write a database and I quite like Elixir, so it was the natural choice for me. And this is of course the Elixir Forum, a good place to discuss such things.

But anyway, there are arguments that can be made in Elixir’s favor here. First of all, we should avoid reductive statements about performance. Things are never so simple. When designing a distributed database there are a number of different subsystems to implement, each of which have their own performance characteristics. A storage engine, for example, might benefit greatly from low-level control over exactly how memory is allocated.

But, on the other hand, a lot of the code for a distributed database is business logic (which has very strong correctness requirements but performance is less important) and various forms of message passing. The thing about the BEAM is it’s really, really good at passing messages around. They’ve been optimizing that one use-case for like 40 straight years.

So if you want to implement a database in C++, you have to design an actor model/message passing framework yourself. This is, in fact, what the FDB team did 15+ years ago. And what they ended up with is the purest embodiment of the “poorly specified implementation of half of Erlang” snowclone you can imagine. All the good stuff like preemptive scheduling, process isolation, error handling, all of OTP. It’s all missing. I mean seriously, go and try to actually read the FDB source code. It’s not exactly beautiful.

Put simply, if you were going to implement a distributed database from scratch in C, properly, you would end up re-inventing all of Erlang/OTP/BEAM first. And then you have to catch up to 40 years of their performance improvements. I don’t know about you, but I don’t think I can solo that one lol.

Now there are parts of building a database that are performance-sensitive in such a way that they are slow when written in Elixir. Maybe not as slow as you think; I need to do more benchmarking but I think my concurrency control is within 50% of the performance quoted in the FDB paper, and all I did was naively implement it on top of ETS.

But for those slow parts, we have NIFs. Down the road I can just swap the slow Elixir parts out for C or Zig or whatever if I want to. The BEAM was designed to do this!

Performance aside, though, the advantage for Elixir really comes down to extensibility. This has come up a couple times up-thread WRT “layers”, but FDB was always meant to be less of a database and more of a “tool for building databases”. I think that paradigm could be considerably more powerful in Elixir, as it allows you to write the layers with a level of integration that is hard to achieve with something like FDB. Perf is not enough.

Ideally FoundationDB + SQL compatibility. Sorry for low-effort response but lately I’ve been fangirling over FoundationDB way too much.