Would relational databases scale as well (or better) than their NoSQL counterparts if we drop the relationships?

Question

Disclaimer: This is a broad question, so it could be moved to a different source (if the admins find it appropriate).

All the cool kids seem to be dropping relational databases in favor of their NoSQL counterparts. Everyone will have their reasons, from scaling issues to simply being on the bleeding edge of tech. And, I am not here to question their motives.

However, what I am interested in is whether any NoSQL transitions ever validated the performance (maintenance) gains over a traditional RDBMS when relationships were dropped. Why would we want to use a RDBMS when the core reason it exists is dropped? A few reasons come to mind

1. 30+ years of academic and work research in developing these systems
2. A well-known language in Structured Query Language (SQL).
3. Stable and mature ORM support across technologies (Hibernate, ActiveRecord)

Clearly, in the modern world where horizontal scaling is important, there is a need to make sure that shards are fault tolerant, updated within the time intervals required by the app, etc. However, those needs shouldn't necessarily be the responsibility of a system that stores data (case in point: ZooKeeper).

Also, I acknowledge that research should be dedicated to NoSQL and that time spent in this arena will clearly lead to better more internet worthy technologies. However, a comparison of sorts between NoSQL and traditional RDBMS offerings (minus relationships) would be useful in making business decisions.

UPDATE 1: When I refer to NoSQL databases, I am talking about data stores that may not require fixed table schemas and usually avoid join operations. Hence, the emphasis in the question on dropping the relationships in a traditional SQL RDBMS

Answer 1

I don't find that inter-table relationships are the main limiter for scalability. I use queries with joins regularly and get good scalability if indexes are defined well.

The greater limiter for scalability is the cost of synchronous I/O. The requirements of consistency and durability -- that the DBMS actually and reliably saves data when it tells you it saved data -- is expensive.

Several NoSQL products that are currently in vogue achieve great performance by weakening their consistency and durability guarantees in their default configuration. There are many reports of CouchDB or MongoDB losing data.

There are ways you can configure those NoSQL products to be more strict about durability, but then you sacrifice their impressive performance numbers.

Likewise, you can make an SQL database achieve high performance like the NoSQL products, by disabling the default features that ensure data safety. See RunningWithScissorsDB.

PS: If you think document-oriented databases are "cutting edge", I invite you to read about MUMPS. Everything old is new again. :-)

Answer 2

There seem to be at least two misconceptions that might be implied by this question. Firstly "NoSQL" does not mean "non-relational", it just means something other than SQL. So a RDBMS could be a NoSQL DBMS too.

Secondly, an RDBMS has nothing much to do with relationships* per se. Relationships are not part of the relational model and they can exist in non-relational databases as well (including No-SQL ones). The "relational" part of RDBMS refers specifically to relations - i.e. the data structure more commonly called a "table" (and never called a "relationship"). The question seems to be mixing up those two important and very different things: relation and relationship.

Since the existence of or absence of relationships has nothing to do with whether a database is relational or not, I'm not sure what the question is really asking. If I've misunderstood something then maybe you could clarify the question a bit.

*A relationship is an "association among things" - or sometimes a database constraint that enforces a rule about such associations.