RDBMS Shortcomings and Band-Aids or What Lead to NoSQL

About:

RDBMS

NoSQL databases

James Phillips’^[1] version of what lead to NoSQL:

RDBMS: shortcomings and band-aids

It remains a centralized, “scale-up” technology; runs on complex, proprietary, expensive servers; and handling more users requires getting bigger (and even more expensive) servers (for increased CPU, memory and I/O capacity).

Running RDBMS technology in an otherwise distributed architecture highlights its lack of flexibility for “rightsizing” the database in real time to fit the needs and usage patterns of the application. (The Web logic layer scales out; the relational database, well, can’t).

The rigidity of the database schema — the fact that changing the schema once data is inserted is A Big Deal — makes it very difficult to quickly change application behavior, especially if it involves changes to data formats and content.

Recognizing these shortcomings of RDBMSs for modern interactive software applications, developers and practitioners have come up with some workarounds — for example, sharding, denormalizing, and distributed caching — which, while useful to a limited degree, are really just Band-Aids that ease symptoms, but don’t fight the disease.

The Couchbase Why NoSQL paper available here provides more details on this topic.