The «NoSQL» label covers databases that are very different from one another, united mostly by what they are not: they do not organise data in relational tables with a rigid schema. Talking about them as a single technology leads to misguided comparisons such as «is SQL or NoSQL better?». The useful question is a different one: which data model best represents the problem to be solved and the questions that will be asked of it?
Document databases
A document database stores self-contained records, usually in a JSON-like format. Each document can contain nested fields and lists:
{
"_id": "order-1042",
"date": "2025-03-10",
"customer": { "name": "Anna Verdi", "city": "Padua" },
"lines": [
{ "product": "Lamp", "quantity": 1, "price": 49.0 },
{ "product": "Bulb", "quantity": 3, "price": 4.5 }
]
}
The order and all its lines are read and written in a single operation, with no joins. The schema is flexible: two documents in the same collection can have different fields. MongoDB is the best-known example, and relational databases such as PostgreSQL also offer indexable JSON column types.
Suitable for: product catalogues with highly variable attributes, CMS content, user profiles, data that is always read as a single block.
Watch out for: data duplicated across documents. If the customer's name is copied into every order, changing it means updating many documents. Schema flexibility also moves validation into application code: if nobody writes it, the data becomes inconsistent.
Key-value databases
This is the simplest model: each key maps to a value, and the database does not care what the value contains. The operations are essentially «write this key», «read this key», «delete this key». Redis is a very widespread example; it works mainly in memory and also offers structures such as lists, sets and counters.
Suitable for: caching the results of expensive queries, user sessions, counters, job queues, rate limiting.
Watch out for: you cannot search on the contents of the values. If you need «all users in Padua», a pure key-value store will not help. If data lives only in memory, you need to understand how and how often it is saved to disk.
Wide-column databases
Wide-column databases, such as Apache Cassandra, organise data into rows identified by a partition key and distributed across many servers. They are designed for very high write volumes and to stay available even when some nodes do not respond.
Modelling follows the opposite logic to relational design: you start from the queries you will run and build one table for each, accepting data duplication. The partition key decides which server the data goes to, so it must be chosen so that the load spreads evenly.
Suitable for: sensor data, event logs, large-scale time series, activity histories.
Watch out for: queries not anticipated at design time are hard or impossible to run efficiently. There are no joins.
Not to be confused with the columnar databases used for analytics, which store data column by column to speed up aggregations over large tables: a different concept, despite the similar name.
Graph databases
A graph database stores nodes (people, products, places) and relationships between nodes (knows, bought, located in), both with properties. Neo4j is one of the best known. Its strength is traversing relationships: «friends of Anna's friends who bought the same product» is a natural query, whereas in a relational database it would require many nested joins and get slower with each additional level.
Suitable for: social networks, recommendation systems, dependencies between components, network and path analysis, spotting suspicious patterns in transactions.
Watch out for: for data that is not really a network, the model brings no benefit and traditional analysis tools are less mature.
A quick comparison
| Family | Unit of data | Strength | Typical limitation |
|---|---|---|---|
| Document | JSON document | Flexible schema, block reads | Duplication, consistency left to code |
| Key-value | Key/value pair | Speed and simplicity | No search on content |
| Wide-column | Row in a partition | Writes at large scale | Queries must be planned in advance |
| Graph | Nodes and relationships | Traversing connections | Little use for non-network data |
When relational is still the best choice
For managing orders, invoices, customer records and stock, that is, highly interconnected data with consistency rules and questions that change over time, a relational database is usually still the most solid choice. It offers constraints, transactions spanning several tables and the ability to ask questions nobody had anticipated. Many real systems combine several models: a relational database as the main store, a key-value store as a cache, a search engine for full-text search.
In short
- «NoSQL» refers to different families, not a single technology.
- Document databases are flexible but move consistency into the code.
- Key-value stores are extremely fast but do not allow searching on content.
- Wide-column stores handle huge write volumes if the queries are known in advance.
- Graphs excel at relationships; for business data, relational is often still the best choice.
