What is NoSQL and when is it a good fit?

NoSQL is not one technology. Document stores, key-value stores, wide-column stores and graph databases all fall under the label, and they solve different problems. The common thread is that they do not require a fixed relational schema and are usually designed to scale horizontally across many nodes.

{
  "orderId": "ord_1042",
  "customer": { "id": "cus_7", "name": "Asha" },
  "items": [
    { "sku": "sku_1", "qty": 2, "price": 499 },
    { "sku": "sku_9", "qty": 1, "price": 1299 }
  ],
  "status": "paid"
}

What you gain and what you give up

• Gain: flexible documents, horizontal partitioning, and low-latency access by key
• Gain: data can be stored in the shape the application reads it
• Give up: joins, ad hoc queries, and strong multi-object guarantees in many systems
• Give up: the database rarely enforces relationships for you, so the application owns integrity

A good fit is a workload with known access patterns, high write or read volume, and data that naturally groups by an entity. A poor fit is a reporting system that needs arbitrary joins and changing questions, because every new query may require a new index or a data copy.