Si vos données sont "hautement relationnelles", alors puis-je vous intéresser à une... euhm... base de données relationnelle ? Il a un support de première classe pour cela, et est accessible via une interface familière de type SQL (à savoir SQL).
Si vous avez besoin d'évolutivité en raison de beaucoup d'utilisateurs, et non en raison de rapports extrêmement gros ou complexes, il suffit d'ajouter plus de répliques en lecture seule et vous'êtes fait. La mise en cache et les rafraîchissements planifiés sont extrêmement utiles (parfois, les données n'ont pas besoin d'être en "temps réel" - un rafraîchissement nocturne est parfois suffisant ; et interroger les mêmes données à 1 minute d'intervalle n'est pratiquement jamais utile).
Si vous avez tellement de données qu'elles ne tiennent plus nulle part (comme, des pétaoctets), alors peut-être que NoSQL peut aider. Ce n'est pas un problème que vous n'ayez pas de JOIN (sauf si vous devez prendre en charge des rapports ad hoc) parce que vos données peuvent être dénormalisées à l'entrée (d'ailleurs, consultez les vues matérialisées - cela peut augmenter massivement vos performances de lecture en SQL normal, si l'espace de stockage n'est pas un problème).
Mais si votre problème de performance est dû à des requêtes complexes (où le processus de "matérialisation" lui-même prend trop de temps), alors peut-être consultez les trucs "Big Data". Il existe des moteurs SQL qui tournent sur Hadoop, par exemple Vertica (et bien d'autres).
C'est une question de temps.