What is it? #
Relational databases store rows in tables with a fixed schema and let you combine them with joins. PostgreSQL and MySQL are the common choices.
NoSQL is not one thing. It covers document stores, key-value stores, wide-column stores and graph databases, each solving a different problem.
The honest summary: relational databases are the right default for most applications, because most applications have related data and benefit from constraints, joins and transactions.
NoSQL earns its place for specific shapes: huge key-value workloads, deeply nested documents that are always read whole, time-series data, or relationship-heavy graphs.
Think of it like this #
A relational database is a filing system with standard forms and cross-references. Every record has the same fields, and you can ask "all invoices for customers in Pune" because the links exist.
A document store is a set of folders, each holding whatever that case needs. Flexible and fast to read as a unit — but answering a question across all folders means opening every one.
Simple example #
An e-commerce system has customers, orders and products, all related. That is relational. Its product catalogue has wildly different attributes per category, which suits a document field. Its session store is pure key-value.
Code #
-- Relational: the relationship is explicit, the join is one query
SELECT c.name, COUNT(o.id) AS orders, SUM(o.total) AS spend
FROM customers c
JOIN orders o ON o.customer_id = c.id
WHERE o.created_at >= '2026-09-01'
GROUP BY c.name
HAVING SUM(o.total) > 10000
ORDER BY spend DESC;// Document store: the order embeds everything it needs
{
"_id": "ORD-1",
"customer": { "id": 7, "name": "Ravi", "city": "Pune" }, // duplicated
"lines": [
{ "sku": "P-1", "name": "Keyboard", "qty": 2, "price": 2499 },
{ "sku": "P-2", "name": "Mouse", "qty": 1, "price": 899 }
],
"total": 5897,
"placed_at": "2026-09-22T10:15:00Z"
}
// One read returns the whole order. But if Ravi changes his name,
// every order document holding a copy is now out of date.The families
Relational PostgreSQL, MySQL related data, joins, constraints, transactions
Document MongoDB, Couchbase self-contained records, flexible fields
Key-value Redis, DynamoDB simple lookups by key, very high throughput
Wide-column Cassandra, HBase huge write volume, time-series, known access patterns
Graph Neo4j relationships are the main query, many hops
Search Elasticsearch full-text search and rankingQuestions that actually decide it
1. Is the data related, and will you query across those relations? → relational
2. Do you need multi-record transactions? → relational
3. Is a record always read and written as one whole unit? → document
4. Is it lookup-by-key at very high volume? → key-value
5. Are relationships themselves the query ("friends of friends")? → graph
6. Is it ranked full-text search? → search engineHow it works #
The SQL query joins two tables, groups, filters on an aggregate and sorts — in one statement the database optimises as a whole. Doing the same across documents usually means several queries and aggregation in application code.
The document example shows both the strength and the weakness. One read returns everything needed to display the order, with no joins. But the customer's name is duplicated into every order, so a name change means updating many documents or accepting that historical orders show the old value.
Interestingly, that duplication is sometimes exactly right. An order should record the price at the time of purchase, not follow later price changes. Denormalisation is a deliberate choice, not automatically a flaw.
Schema flexibility cuts both ways. Adding a field needs no migration, which is convenient — and after two years, nobody knows which of the seven historical shapes a document might have.
Modern relational databases blur the line considerably. PostgreSQL has a JSONB column type with indexing, so you can keep relational structure for the parts that are related and flexible documents for the parts that are not. That combination is often the practical answer.
On scaling: relational databases scale writes horizontally with more difficulty, which is the grain of truth behind "NoSQL scales better". But a single well-tuned PostgreSQL instance handles far more than most applications will ever need.
Real-world use #
The common production pattern is polyglot: PostgreSQL as the source of truth, Redis for caching and sessions, Elasticsearch for search, and object storage for files. Each tool does what it is good at.
Choosing NoSQL for flexibility early and discovering later that you need joins and transactions is a well-documented and expensive path. Choosing relational and adding a JSON column where flexibility is genuinely needed is easier to reverse.
Where NoSQL is clearly right, it is very clearly right: session stores, high-volume event ingestion, IoT time-series, recommendation graphs and full-text search are not jobs for a relational table.
The decision should follow your access patterns, not the technology's reputation. Write down the five queries your application makes most, and pick the database that answers them well.
Common mistakes #
- Choosing a document store to avoid schema design, then needing joins six months later.
- Assuming relational databases cannot scale — most applications never reach the limit.
- Duplicating data across documents without a plan for keeping it consistent.
- Running five database technologies when one would do, multiplying operational work.
- Ignoring that your data is relational because the current record looks self-contained.
Practice #
Take a system you know and list its five most frequent queries. For each, note whether it crosses relationships, needs a transaction, or reads one record whole. Then decide which storage each part belongs in and write two sentences justifying the primary choice.