Hacker News Reader

Comment by mrslave | Hacker News Reader

Slightly off-topic from someone who hasn't touched Erlang in almost 20 years: if my app is distributed with Erlang/Elixir, I kind of feel like my choice of database should be something with excellent horizontal scaling too. Can someone offer some insight into the trends in 3rd-party tools like databases for Erlang applications?

View on HN

Erlang already comes with a distributed DBMS called Mnesia https://erlang.org/doc/man/mnesia.html , which under the hood uses ETS/DETS depending on the configuration. In distributed Erlang projects you'll find that or abstractions over it. Mne sia makes the most sense in mu opinion when you only have 1-2 relations or just need some kind of distributed cache.

In Elixir apps you'll frequently find the aforementioned Ecto "ORM", which has adapters to different DBMSs like MySQL, PostgreSQL, and even Mnesia.

The one sort-of thorny piece with Mnesia is querying the DB. The syntax for select is not super straightforward and involves writing matchspecs (http://erlang.org/doc/man/ets.html#match-specifications) which are non-trivial.

Mnesia lets you do a lot of cool things (in memory DB by default! Super fast!) but it also has some pitfalls (Doesn't write to disk by default! Lose all your data when you restart the BEAM!).

Generally, I think it's a fine system if you're willing to put in the time to optimize it.

Postgres? ;) In all seriousness though, I wouldn't really expect database needs for Erlang & Friends to be that different from other languages. My current employer has a vertically scaled AWS RDS Postgres as companion for an Elixir app and it's worked great. (Ecto in particular is an excellent ORM.) If your app truly needs zero downtime or ultra-low latency then there are other options.

I've had interesting exchanges with a guy who does work on CouchDB. That is built with Erlang and should scale quite well in what sounds like a resilient way. Haven't dug in.

Horizontal scaling of the DB seems like a problem in many architectures. For SQL I'd be looking at CockroachDB as it is Postgres-compatible and is built with scaling out in mind. Haven't tried it though. Most of my work hasn't needed that for the DB recently.

I love the notion of co-located processing and data, but most of the data stores dont quite embrace it. Well actually Riak does quite well if you're fine with a dynamo like kv store. The riak library is actually pretty nifty for distributed computations. But with Basho out of business it's harder to justify. Plus KV stores really aren't as usable as good ole sql. In that realm there's ActorDB, but I've not been able to figure out how to run it inside my own beam cluster rather than standalone.

Hadn't heard of ActorDB. Interesting. But is it alive? Seems inactive.

It seems dead and it relies on some (older) rebar stuff. And the custom "actor" syntax would probably break Ecto..

Probably CockroachDB (https://www.cockroachlabs.com/)? It's wire-compatible with postgres so any library with a postgres driver will work.

Elixir has the excellent Ecto package which talks to many SQL dbs, Postgres being the default.

Reply on news.ycombinator.com