| Features |
|---|
| Relational(SQL) | Non-Relational (NoSQL) | Non-Relational (NoSQL) | |
|---|---|---|---|
| Data Type | Hard to store rich data type | Able to store literally any type of data | |
| Scaling | Not trivial to scale, and not cheap | Scaling is automatic and transparent | |
| Cost | Expensive to build and maintain | Around 10% cost to Relational DB | |
| Representation | Represents data in tables and rows | Represents data as collections of JSON documents | |
| Query | Structured Query Language (SQL): makes SQL injection attack possible | Object Querying: intuitive, passing a document to explain what you're querying for | |
| Multi-originated | JOIN operation: perform query across multiple tables | Multi-dimensional data type: support array and even other documents | |
| Atomic Style | Support Atomic Transaction: able to contain multiple operations with a transaction and roll back the whole thing if it were a single operation | Does not support Atomic Transaction, but single operations are atomic | |
| Schema | Require to define tables and columns before storing. Each row has same columns | No schema, drops in documents. Two documents in a collection can have different fields | |
| Perfomance | Poor performance when using ORM | Perform much better | |
| Applicaton | Better when: Data structure fits nicely into table and rows. Or Require SQL or transactions | Better when: Data seems complex in relational database system. Or De-normalizing database schema or coding around performance. Or Can not pre-define schema or want to store records |
NoSQL's many forms (e.g. document-based, graph-based, object-based, key-value store, etc.) may or may not be based on a single underpinning mathematical theory. As S. Lott has correctly pointed out,hierarchical data stores do indeed have a mathematical basis. The same might be said for graph databases
.