It is what it is. It's useful to prototype with in Erlang. It may be useful to ship with. If Mnesia turns out not to fit your problem, here in 2015, you've got literally <i>dozens</i> of choices of alternate DB, with all sorts of consistency and distributibility and performance characteristics.<p>My guess is that if somehow Erlang was where it was in 2015 except it didn't have Mnesia, nobody would really perceive much of a hole there, and nobody would write it, because of the database explosion we've seen in the past 10 years. But it is there, and if it works for you, go for it.<p>My only slight suggestion is that rather than inlining all your mnesia calls, you ought to isolate them into a separate module or modules or something with an interface. But, that's not really because of Mnesia... I tend to recommend that anyhow. In pattern terms, I pretty much <i>always</i> recommend wrapping a Facade around your data store access, if for no other reason than how easy it makes your testing if you can drop in alternate implementations. And then, if mnesia... no, wait... And then, if $DATABASE turns out to be unsuitable, you're not stuck up a creek without a paddle. With this approach it's not even all that hard to try out multiple alternatives before settling on something.
I'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'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't deal with network failures well out of the box (you need something like <a href="https://github.com/uwiger/unsplit" rel="nofollow">https://github.com/uwiger/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.
This has little to do with databases, erlang or mnesia, its just a moan against people writing ad tech.<p>mnesia is a database for the 90's because it was written by smart people in the 80's and like most of the rest of the otp stack was fairly under used or maintained.<p>I have a huge amount of respect for Klacke and the original authors behind a lot of this tech, however the erlang community that followed seems to suffer some cognitive dissonance around what problems it solves and how well they are doing them. It would be hard to pick a database less suitable for SMB use than a domain specific database in a niche ecosystem.
I have much the same sentiment with SQLite. Much dismissed as a toy database, but absolutely appropriate for 99% of my clients - small and medium businesses, the same as mentioned in thread.
Many valuable considerations inside, read the post.
Starting with this thought in the question: 'I hate transiting syntactic boundaries when I'm programming'.<p>But the answer is such a broader evaluation of the utility of the tools we are using, related to what we use those in.<p>And some rants that I share:
"but really boil down to adtech, adtech, adtech, adtech, and some more adtech, and marketing campaigns about campaigns about adtech."
Erlang (and by association Elixir) tooling has a nice progressive approach to managing state.<p>Agent -> ets -> dets -> mnesia -> riak (or sql tooling etc.)<p>(Agent <a href="http://elixir-lang.org/docs/v1.1/elixir/Agent.html" rel="nofollow">http://elixir-lang.org/docs/v1.1/elixir/Agent.html</a> is just a state-holding process. Erlang folks can probably write one of these in their sleep, Elixir added a bit of wrapping-paper around it.)<p>If you're writing an app, I think it's best to be storage-agnostic from the get-go. You shouldn't be building up queries in your core app code- push it to the edge of your code, because otherwise it's not separating concerns. All your app (business logic) code should delegate to some wrapper to work out the specifics of retrieving the data; your app code should just be calling something like Modelname.specific_function_returning_specific_dataset(relevant_identifier) and let that work out the details. That way, if you ever upgrade your store, you just have to refactor those queries but your app code remains the same. On top of that, in your unit tests you can pass in a mimicking test double for your store to do a true unit test, and avoid retesting your store over and over again wastefully. (You'd still of course have an integration test to cover that, but it wouldn't be doing it <i>on every test</i>.)
Not that this hasn't generated good talking points, but I was there at the workshop the OP mentioned and Fred's remark was very much said in passing to a small group of people during a break and he didn't seem to be making an intentionally negative remark. He certainly wasn't stating it as instructional fact.
Well, you could summarise this article by saying: "Just because something got invented 25 years ago it doesn't mean it is useless".
On the contrary - it is worth taking a look on technology that survived 25 years in the wildness.
The article is light on actual details and heavy on rants about the current state of products built on the web.<p>However there is 1 thing that mnesia got absolutely and totally right. Database schema upgrades. You can create an mnesia database and upgrade it's schema on the fly as a part of it's operation without once bringing it down or running a script. I did this[0] for a toy project I did in erlang once that I unfortunately never finished since the need for it disappeared.<p>[0]: <a href="https://github.com/zaphar/iterate/blob/master/src/db_migrate_tools.erl" rel="nofollow">https://github.com/zaphar/iterate/blob/master/src/db_migrate...</a>
By the same argument, though, why not just use Postgres? And I write that as a fan of Erlang. Indeed: <a href="https://github.com/epgsql/epgsql" rel="nofollow">https://github.com/epgsql/epgsql</a>
I can't say I found the piece particularly insightful.<p>It seemed to imply that mnesia is the DB of the future as soon as everyone realises that everything they are doing is completely wrong and they should be doing things that are more suited to mnesia. Without saying what those things are.<p>I actually found one of the child comments [1] was pushing in a better direction. Essentially, the vast drop in $/TB of storage means that persistence of time series/ event type data is practical for the masses now. Sure it's found a niche in ads on the web, but it has much wider applicability than that.
I personally think that Erlang is particularly well suited to this space.<p>[1] <a href="http://erlang.org/pipermail/erlang-questions/2015-October/086432.html" rel="nofollow">http://erlang.org/pipermail/erlang-questions/2015-October/08...</a>
> This is much more interesting than chasing click statistics in the interest of brokering ad sales at the speed of light so that users can continue to ignore them.<p>That comment really packs a punch and should get much wider visibility. Ad tech and related software is where <i>way</i> too much of our collective efforts are going.