If you ask me about what NoSQL database to chose, well then you should check out RethinkDB. http://www.rethinkdb.com/faq/
RDMS force you do defined data structures beforehand. Normalize everything (I think people stop at normalization level 2 or 3 because its impossible to know best data structure before app is used by real users), create 2 column tables to store relations (SQL doesn't seem to be the optimal language), put structural knowledge into query (oh but for some relations its good 'huh?) which gets then hidden away by any type of ORM (yeah who doesn't really likes to deal with SQL).
NoSQL is just a term for all types of databases. Key Value Stores, Column stores, big tables, document stores, graph databases and any mix of them.
If you just choose "NoSQL" because its hip and cool, well then you might run into same problems like everyone has with SQL databases. You can use MySQL/MariaDB to mimic data modeling experiences like with document databases or like with key value stores.
Choosing "NoSQL" for performance reasons is also not a good answer. Imagine having a all round vehicle (we can call it SQL) trying to benchmark it against a collection of cars (we can summarize them under term of NoSQL). Starting challenges in different data structure categories and query strategies. Measuring any data structure and read/write query strategy against specialized NoSQL databases is kinda unfair. But its only not fair because engineers have used SQL for too long, trying to solve every problem within SQL databases.
In NoSQL land it is as easy to fall into same traps like it is in SQL land. The biggest difference is DX (Developer eXperience). Because not having the need to press a specific mind model into a normalized data structure, then hiding it behind a ORM -> increases (intangible) productivity. But reaching performance goals can be tough too. Adding caches, using different NoSQL databases for different data structures or accessing strategies can become cumbersome too. Next problem is you have different variants of same data spread across whole architecture. But if each architecture and its shards is chosen wisely, then it still can be better experience than with any pure SQL database.