Alternatives for MongoDB?

I wanted to know which NoSQL databases offer official clients for elixir/erlang?
We currently have mongo as our database and the application is written in JAVA. We are considering porting it to elixir, but since mongo driver for elixir isn’t mature enough, we are looking for an alternative.
Which database are you using and what would you recommend?

What are your requirements? And… any reason why you wouldn’t want to use Postgres?

Also did you see the MongoDB adapters here:

We were having systems running on MySQL previously and chose mongo due to scalability issues. And postgres doesn’t natively provide sharding. I think postgres is more suited for read-heavy workloads. Our workloads are more write-heavy, so we chose Mongo.

I checked the adapters for mongo and most of them aren’t maintained anymore.

Also from the author of the package:

1 Like

What features are you looking for from a mongo driver? There has been some improvement on it since I wrote that.


Have you checked the Basho products one of which is Riak, and it’s written in Erlang?

I am not affiliated but heard people praising them. Never had the chance to try any of their products so far though.

1 Like

Sorry, but I haven’t used the driver, so not aware of the current limitations (if any) I was going through the discussion on the previously mentioned thread and thought it wasn’t actively maintained.

I think Riak is more of a Key-Value store than a NoSQL database. Also it is eventually consistent and doesn’t support atomic updates.

I’ll admit there hasn’t been much work done on the driver lately, the last commit was about a month ago, but it is still maintained. If you give it a look and there are some features that are not currently in there, just post an issue and we can probably get it sorted out.


what is the nature of the data? using postgres with or comes to mind… admittingly I would think “normal” postgres is also up for the job…

that being said I would cautiously warn against changing both the DB and the App layer(to elixir I assume) at the same time… but all depends on complexity etc. etc.

I would try and get something going using the old DB and Elixir (perhaps reverse proxy the Java app and then build out slowly… Migrating from Rails to Elixir, bit by bit)


Yep, even raw-bog-standard PostgreSQL has fantastic nosql style storage with far more features than something like mongodb. Although I personally always question why someone thinks they need a nosql style storage, having a properly typed system is always far safer and often much faster. :slight_smile:


The data has multiple objects which can be owned by multiple owners (sub-systems). A subsystem can replace the current object with a new object and assign its properties to different subsystems. The number of levels of the number of object is non-deterministic. It depends on the runtime inputs. And we also do a lot of scheduling based on priority, cost optimisation, etc on top of these subsystems. We have borrowed some concepts from FBP as well. I think modelling such kind of data in a traditional database isn’t a good idea.

1 Like

The most compelling argument that I have heard is from this video here. Keep in mind I have not verified the information, but from a high level, it makes sense.

The argument being, SQL databases are optimized for memory. Which made sense for when they were made because memory was one of the most expensive pieces in a datacentre. Now memory is fairly cheap and CPU’s have become the most expensive pieces in a datacentre. NoSQL apparently optimizes for the CPU, which is why it generally has a fairly “dumb” querying mechanism.

But to me, that just seems to move the CPU usage from the database and into your application(s). So I don’t really know how it is a win.

I just wish I had a lot of time to dig deep into as many databases as I could in order to find what each of their use cases are. Unfortunately for me, I don’t have that time.


N-to-M join tables.

Unsure what that is modeling but a transaction can do multi-updates atomically.

Join tables don’t care about depth. ^.^

All of which are just normal queries or (materialized) views, which are bliss. ^.^

This is all entirely not only supported by SQL but would be very well modeled as such, plus it helps to think how to model the data as it helps to get the code in better order as well. More ‘types’ is always better. :slight_smile:

I’ve heard that argument many times and also seen it ripped apart many times. What you said at the end is precisely the most cited reason why it fails but that’s not even the biggest reason, which is the failure of typing and reliability around knowing the types.


Seems like I over-simplified the problem statement.

Key-Value stores definitely fall under the category of NoSQL database. Perhaps you’re more specifically looking for a document-oriented database?


No atomic updates and/or the lack of multi-update transactions would be a deal breaker for me as well. But outside of that – and as @axelson said – K/V stores do fall under the NoSQL storage engines category.

You are not giving enough information in order for us to give good advice but as a rule of thumb: run away screaming from any “database” that has no strong typing and structure. Many people have tried it, many times, 99% of them ended up regretting it. The problems are well-documented – one of the most popular ones being that you get an initial burst of productivity… at the cost of maintenance of N versions of the data storage. Forever.

1 Like

It’s new! It’s cool! It’s what all the big guys are using!

NoSQL has use cases, but the installations far outnumber the use cases.

Perhaps a combination of ecto (without ecto_sql) in combination of ex_aws_dynamo? Just a suggestion, I haven’t personally tried this… It would require a bit of elbow grease but it could work.

Alternative DB’s: PosygreSQL, .RIAK, Realm DB, sqllite…

1 Like

Postgresql can store json and jsonb like Mongodb.