@josefrichter I see no answers and thought I would offer my unqualified opinion, as I have given this some thought.

I think this topic is not a casual one and rests on opinions that go beyond Elixir/Phoenix <=> Mongo and into RDBMS vs. NoSQL. I have experienced strong opinions about RDBMS vs NoSQL and I also believe I notice a strong preference for Postgres in the Elixir community. So I offer these opinions gently, and hopefully don’t invite too strong of an opposing reaction.

I also believe NoSQL is young and under-understood. Example: the Normal Forms for relational data were first published over fifty years ago. I am unaware of any equivalent body of guidance and thought for NoSQL. I know of database leaders who share best practices and good ideas, but these have tended to be contextual. E.g. a good design for a NoSQL product catalog at planetary scale. Or how to use NoSQL as an alternative to building a meta model in RDBMS for CRM. And so on.

I have wondered if I could synthesize these learnings into a modest version of the Normal Forms guidance for RDBMS but it hasn’t come to me yet. I remain faithful to what bdtomlin asserts, and so I am replying here, over a year and half later.

First, what are the advantages of NoSQL?

Ecto addresses, to a degree, what I believe to be the most important advantage: centralizing and homogenizing complexity from database technologies and implementation processes, to that of code. With migrations, the schema of your database is defined entirely in Elixir, in a specific manner. So db changes can be accomplished through CI/CD in a standard manner using the same mechanisms and intuitions as with Elixir, because with Ecto DB schema is Elixir. This is wonderful.

Using NoSQL without something like Ecto may allow a software team to gain even greater value - although without such a convention/standard/interface/adapter/etc many teams get into trouble, especially due to the lack of understanding mentioned above. But an adept team that wants to define their own DBAPI can form it to their liking without the constraints of Ecto. Want to allow for multiple versions of your schema at once? Drop a schema version into a standard spot in every document’s metadata, and your DB layer can reason over the schema and what to do about it. This can result in, as an example, global rollouts of a distributed system where schema changes in production without cutover or outage.

This brings us to the second advantage of NoSQL: (better) supporting schema versioning. With RDBMS, to my knowledge, we are stuck with one schema at a time, per database. Nowhere else in our code are we so constrained.

And this brings us to one of the key advantages of NoSQL + Elixir: pattern matching. Avoiding imperative conditions, and using pattern matching, idiomatic Elixir is very nicely able to work with databases returning heterogenous schema versions. If this isn’t immediately obvious to you, see if using an intuitions about pattern against incoming an protocol and across versions. Same thing but from the other side. It’s great. This goes beyond what I’ve outlined here.

Next is that it is often helpful to have entities with differing metadata. Like we learned when we first learned OO that the animal class had the mating_display method, which meant modeling feathers for peacocks, jousting for elk, and makeup and credit cards for humans. A NoSQL vs. RDBMS discussion can, on the NoSQL side, talk about saving the entity type as we did with the schema version above, in this case with the entity metadata vs document metadata. Then in NoSQL you can do what we called at Xbox an “ABC” pattern. Where schema section A contains things true for all types, B contains segregated spaces for each entity to record their type-specific data, and C contains meta-data and other flags, tags, workflow state, etc - information orthogonal to entity type. This is one of those database leader nuggets of wisdom I was lucky to collect.

Bringing that back to Elixir, again we see pattern matching being useful. The database complexity above can get pretty hairy for languages that don’t have Elixir’s expressiveness. But it just fits with Elixir. In a way that RDBMS does, in my opinion, not.

Related to this, implicitly, is the advantage of representing data hierarchy in JSON vs normalizing across tables in RDBMS. I won’t go into this too much because it gets quite technical and is a supporting story to the versioning and typing of schema noted above.

Another nugget of wisdom about NoSQL is making “chunky” documents. People coming from RDBMS to Mongo sometimes design their Mongo collections to be similar to what they would do in an RDBMS. Normal, to be joined. In some situations, particularly at planetary scale, we try to minimize customer-time joins. Map-Reduce is an example of this. Caching user-centered queries is another. Eventual consistency is a consequence of this. This is a big topic, and I’m happy to delve into it in another post or elsewhere, but for the moment, accept that I believe this to be true. If one believes that to be true, then they are moving some of the capability that transactions were giving them to code which eventually makes a piece of data consistent (a misnomer, an entity might never be consistent, but some process is always scuttling around moving it towards consistency, and other processes are caching what data is consistent to a place for rapid retrieval). You know what is super duper helpful for this? Genservers. Bombproof systems that are always running (scuttling) based on patterns (not consistent) creating outputs (consistent data), well, they just fit. Maybe said another way, eventual consistency is well supported by a system that is distributed, reliable, and good at passing many messages around.

I’ve got to go help family get ready for dinner, but that’s a good if not exhaustive representation about some of the strong feelings I have for Elixir+Mongo. I’m just discovered this conversation and super happy to support the Elixir Mongo org. I’m going to try to go find the repo now and see what I can do.