SQL vs NoSQL and when to use

Use SQL when relationships and consistency matter. Use NoSQL when flexibility and scale matter. Neither is a default; the right one usually falls out of the problem once you look at it.

A SQL database is relational: data lives in tables of rows and columns, every row shares the same columns, and tables link through keys. NoSQL is the umbrella for everything else, where records don't have to share a shape and the store is usually built to spread across many machines.

At a glance

Reach for SQL when

• The data has a stable shape and clear relationships.
• You need real transactions, where a group of writes all succeed or all fail together. Money, orders, and inventory live here.
• Queries get involved: joins, aggregations, questions you didn't plan for.
• Integrity matters enough to enforce it in the database, with foreign keys and constraints.

Usual picks: Postgres, MySQL.

Reach for NoSQL when

• The schema changes often, or you don't fully know it yet.
• You need to scale writes across many machines, or handle high throughput.
• The access pattern is simple: look something up by its key and hand it back.
• You'd rather store data pre-shaped for reads than normalize and join later.

NoSQL isn't one thing, though. The four families solve different problems.

Examples

SQL: a bank transfer

Two accounts, one moves money to the other. Both updates happen or neither does.

BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
UPDATE accounts SET balance = balance + 100 WHERE id = 2;
COMMIT;

If the second update fails, the transaction rolls back and no money vanishes. That all-or-nothing guarantee is the thing most NoSQL stores give up. Its formal name is ACID; see ACID transactions.

SQL: an e-commerce order

Users place orders, orders contain items, items point at products.

users >- orders >- order_items -< products

"Every order this user placed, with product names" is one query with a couple of joins. The relationships are the point, and SQL models them directly.

NoSQL document: a product catalog

Different products carry different attributes, so a rigid column layout fights you.

// a shoe
{ "id": "1", "name": "Nike Pegasus", "size": 42, "color": "red" }

// a laptop, same collection, different fields
{ "id": "2", "name": "MacBook Air", "ram": "16GB", "cpu": "M3" }

Each document brings its own shape. In SQL you'd add a column per attribute and drown in nulls, or push it into a JSON blob and lose the point of columns.

NoSQL key-value: a session cache

A session needs to come back in well under a millisecond, and there's nothing relational about it.

SET session:abc123 "{ userId: 5, cart: [...] }" EX 3600
GET session:abc123

Redis stores it by key, expires it after an hour, hands it back instantly. No schema, no joins, nothing to model.

NoSQL wide-column: sensor data

A fleet of IoT devices writes a million points a second. Cassandra spreads those writes across nodes and keeps up; a single Postgres box would fall over. When write volume is the whole problem, this is the shape that survives it.

Most systems mix both

Picking "SQL vs NoSQL" is usually picking what each piece of the system is best at.

                 App
                  │
        ┌─────────┴─────────┐
    Postgres            MongoDB / Redis
    - Users             - Logs
    - Orders            - Analytics
    - Payments          - Chat, sessions

• Amazon: SQL for orders, NoSQL for sessions and caching.
• Uber: SQL for payments, NoSQL for trip and location data.
• Netflix: SQL for billing, NoSQL for recommendations and viewing history.

Decision table

A rule of thumb

If you need relations, transactions, and enforced integrity, that's SQL. If you need scale, a loose schema, and plain lookups by key, that's NoSQL. When you genuinely can't tell, start with Postgres. It also stores JSON with jsonb, so it stretches further than people expect, and you can add a NoSQL store later once a specific pain shows up.