Relational vs NoSQL databases

Document, key-value, wide-column and graph databases — what they're good at and when to choose them.

One size doesn't fit all

Relational databases are the workhorse of business software: flexible queries, joins, constraints and ACID transactions. But some workloads stretch them — massive write volumes, flexible schemas, global distribution, or highly connected data. NoSQL ("not only SQL") is an umbrella term for databases built around different trade-offs.

The families

Type	Model	Examples	Great for
Relational	Tables, rows, joins, SQL	PostgreSQL, SQL Server, MySQL	Business data with relationships and transactions
Document	JSON-like documents grouped in collections	MongoDB, Azure Cosmos DB, RavenDB	Aggregates read as a whole, evolving schemas
Key-value	A key maps to an opaque value	Redis, DynamoDB, Memcached	Caches, sessions, counters, extreme speed
Wide-column	Rows with flexible column families, partitioned	Cassandra, ScyllaDB	Huge write volumes, time series, IoT
Graph	Nodes and relationships	Neo4j	Social networks, recommendations, fraud detection
Search	Inverted indexes over text	Elasticsearch, OpenSearch	Full-text search, log analysis

Normalized vs denormalized

The same order, two ways:

Relational (normalized)            Document (denormalized)
orders:       id=1, customer_id=7  {
order_items:  (1, Laptop, 1)         "id": 1,
              (1, Mouse, 1)          "customer": { "id": 7, "name": "Ada" },
customers:    id=7, name=Ada         "items": [
                                       { "product": "Laptop", "qty": 1 },
                                       { "product": "Mouse",  "qty": 1 }
                                     ]
                                   }

Normalized: each fact stored once; flexible queries and easy updates; reading an order needs joins.
Denormalized: the whole order in one read, no joins; but the customer's name is copied into every order — renaming her means updating many documents.

Model documents around how data is read together: an order and its items, a blog post and its comments.

Scaling and consistency

Many NoSQL databases were designed to spread data across many machines (partitioning/sharding) and to stay available even when some machines can't reach others. The price is often eventual consistency: after a write, some reads may briefly return old data until all copies catch up. You'll meet the underlying trade-off — the CAP theorem — in Distributed systems.

Modern systems blur the lines: PostgreSQL stores and indexes JSON columns, Cosmos DB offers tunable consistency, and relational databases scale reads with replicas.

Choosing

Default to a relational database for core business data. You get transactions, constraints, joins and decades of tooling.
Add Redis for caching, sessions and rate limiting.
Add search (Elasticsearch) when users need full-text search.
Reach for document, wide-column or graph databases when the data model or scale clearly calls for them — not because they're fashionable.

Using several databases for different jobs is called polyglot persistence — common, but each one adds operational work.

In .NET

EF Core targets relational databases (and Cosmos DB). For MongoDB there's an official driver, and StackExchange.Redis is the standard Redis client.

Key takeaways

NoSQL families — document, key-value, wide-column, graph, search — each optimize for different access patterns.
Normalized data avoids duplication; denormalized data avoids joins.
Distributed NoSQL databases often trade strong consistency for availability and scale.
Start relational; add specialized stores for specific needs.