Usrbinbash makes a good point regarding the meaning of “relational”. Many people have come to think that “relational” refers to the relationships between entities in the database, when it really means that the database manages data in tabular form. I think this misunderstanding has become more ingrained because people typically normalize their data in RDBMSs, which necessitates greater use of joins. So, when folks talk about a “relational” workload, they often mean executing ACID-compliant joins over a normalized dataset. Because early NoSQL databases had traded transactional consistency for performance and scalability, there’s been an expectation that NoSQL databases can’t support what some think of as a relational workload.<p>To be fair, in the early days of NoSQL, it was necessary to use denormalization in one’s schema to achieve transactional integrity in the absence of joins. However, distributed databases have since overcome the major challenges of achieving consistency at scale. For example, <a href="http://Fauna.com" rel="nofollow">http://Fauna.com</a> is a serverless, document database which supports ACID transactions via the Calvin protocol. This means that you can execute transactionally consistent joins across collections (“tables”), and either normalize or denormalize your data model for all the same design reasons you might in a traditional RDBMS. The principle difference is that records in Fauna are JSON documents rather than rows in a table.<p>This is not to say that denormalization in modern schema design isn’t beneficial. However, support for ACID joins in a modern document database gives you more latitude in your schema design choices.<p>Full disclosure, I am a Product Manager at Fauna.