“SQL vs NoSQL: How to Choose” article continues the discussion of SQL vs. NoSQL from the “SQL vs NoSQL: The Differences” article. Both should be read in full. But I’ll keep the summary here for future use.
SQL databases:
- store related data in tables
- require a schema which defines tables prior to use
- encourage normalization to reduce data redundancy
- support table JOINs to retrieve related data from multiple tables in a single command
- implement data integrity rules
- provide transactions to guarantee two or more updates succeed or fail as an atomic unit
- can be scaled (with some effort)
- use a powerful declarative language for querying
- offer plenty of support, expertise and tools.
NoSQL databases:
- store related data in JSON-like, name-value documents
- can store data without specifying a schema
- must usually be denormalized so information about an item is contained in a single document
- should not require JOINs (presuming denormalized documents are used)
- permit any data to be saved anywhere at anytime without verification
- guarantee updates to a single document — but not multiple documents
- provide excellent performance and scalability
- use JSON data objects for querying
- are a newer, exciting technology.
SQL databases are ideal for projects where requirements can be determined and robust data integrity is essential. NoSQL databases are ideal for unrelated, indeterminate or evolving data requirements where speed and scalability are more important. In simpler terms:
- SQL is digital. It works best for clearly defined, discrete items with exact specifications. Typical use cases are online stores and banking systems.
- NoSQL is analog. It works best for organic data with fluid requirements. Typical use cases are social networks, customer management and web analytics systems.
Few projects will be an exact fit.