Nun, was die MongoDB und ähnliche Datenbanken angeht, so unterscheiden diese sich nur in der Speicherungsform eines Dokuments (= Zeile).
Für die Abfrageoptimierung müssen trotzdem Indizes erstellt werden, Join-Beziehungen, also Relationen, sind dort genau so möglich und auch nötig.
Auch wenn man dokumentenbasiert speichert, ist das Prinzip der Abfragetechnik zwischen relationalen DB's und Dokumenten-DB's identisch.
Dass Dokumente beliebige Schlüssel-/Wertpaare aufweisen, bedeutet doch nichts anderes, als das nicht vorhandenen Werte zu Schlüsseln wie in der relationalen Welt auch, als NULL-Ergebnis bewertet werden.
Die Speicherungsform als typlose Daten, also egal ob Zeichen oder Zahlen oder Subdukumente als XML/JSON ist bei Aggregation wiederum kontraproduktiv, da hier erst Umformatierungen von Zeichen in Zahlen erfolgen müssen und das kostet Rechenzeit. Dies mag marginal erscheinen, aber Millionen von unnötigen Berechnungen drücken sich letztendlich auch in Sekunden aus.

Wie in einem anderen Thread schon mal beschrieben, habe ich für statistische Zwecke eine relationale Tabelle mit Voraggregaten auf der IBM i erstellt. Dieser Job auf einer P9 lief zwar knapp 3 Stunden, produzierte allerdings ca. 100 Millionen Ergebniszeilen mit mehreren 100-Millionen Abfragen auf anderen Tabellen.
Ich bezweifle, dass andere Datenbanken dies ohne massive Parallelisierung über diverse Server (Skalierungen) mit entsprechendem Verwaltungsoverhead hinbekommen.

Auch die Erweiterbarkeit der DB2 for i lässt keine Wünsche offen.
Solange man (wie bei anderen DB's auch) sich ausschließlich im SQL-Bereich aufhält, lassen sich Tabellen jederzeit erweitern, mittels View und Instead-Of-Triggern sogar programmneutral vollkommen umbauen.
Für ERP-Zwecke ist eine relationale Datenbank wie die DB2 for i, in meinen Augen, unschlagbar.

Übrigens:
NoSQL steht für "Not only SQL". Dies sieht man dann auch an den Abfragekonstrukten, die zwar nicht wie SQL aussehen, sich aber 1:1 in SQL umsetzen lassen.