NoSQL Concepts

Main families

Kind	Stores	Typical use
Key-value	Values looked up by a key	Caches, sessions, simple lookups
Document	JSON-like documents	Content, catalogues, records with varying fields
Wide-column	Rows with many flexible columns, grouped by key	Very large volumes of writes, time series
Graph	Nodes and relationships	Social networks, recommendations, routes

The families matter more than the product names.

How it differs from relational

• Flexible schema: documents in one collection can have different fields. This is quick to start with, but the structure is then enforced only by your code, so errors show up later.
• Denormalized by design: related data is often embedded in one document so it can be read in one go. Updating copies of it becomes your responsibility.
• Joins are limited or absent, so you design the data around the queries you will run.
• Scaling out: many were built to spread data across many machines.
• Consistency trade-offs: some offer weaker guarantees than relational transactions in exchange for availability and speed. You may meet the term “eventual consistency”; see Distributed Systems Basics.

The lines are blurring: relational databases support JSON columns, and many NoSQL products now offer transactions and query languages.

Choosing

Relational databases remain a strong default for structured business data with relationships and integrity rules. Consider a NoSQL store when the data is naturally a document or a key lookup, when you need massive scale or when access patterns are simple and known. Using more than one store in a system is common, for example a relational database plus a cache.

Try it

Take the customers and orders example from Relational Database Concepts and write one order as a single JSON document that embeds the customer name and the order lines. List one advantage and one risk of this shape compared with separate tables.