SQL vs NoSQL

When you pick a database for an app, you face one big choice early on: SQL or NoSQL. SQL means a relational database (data stored in tables with rows and columns, like a spreadsheet that enforces rules). NoSQL (“not only SQL”) is a family of databases that store data in other shapes — documents, key-value pairs, and more. This page explains the real difference in plain English, shows a side-by-side comparison, and gives you clear “when to use which” guidance. The short version: most apps should start with SQL, and you should only reach for NoSQL when you have a specific reason.

What “relational” (SQL) really means

A relational database stores data in tables. Each table has a fixed schema — a defined list of columns and their types, decided up front. For example, a users table might have an id (a number), an email (text), and a created_at (a date). Every row must follow that shape.

The power comes from three things:

Joins — you can link tables together. An orders table can reference the users table by user_id, and a single query can pull a user and all their orders without storing the data twice.
Constraints — the database enforces rules. A NOT NULL column can never be empty; a UNIQUE column can never have duplicates; a FOREIGN KEY stops you creating an order for a user who does not exist.
ACID transactions — ACID stands for Atomicity, Consistency, Isolation, Durability. In plain terms: a group of changes either all succeed or all fail together (you can never charge a card without also recording the order), and once the database says “saved”, the data survives a crash.

You talk to relational databases with SQL (Structured Query Language), a readable language that has been the industry standard since the 1980s.

SELECT u.email, o.total
FROM users u
JOIN orders o ON o.user_id = u.id
WHERE o.total > 100;

When to use SQL: When your data is structured and related (users, orders, payments, products), when correctness matters (anything involving money or counts), and when you are not sure yet — SQL is the safe default for the vast majority of applications.

The NoSQL families

NoSQL is not one thing. It is an umbrella over several different storage styles. The two you will meet most often as a DevOps engineer are document and key-value stores.

Document databases

A document database stores each record as a self-contained document, usually in JSON-like format (JSON is a text format for nested data, with keys and values). There is no fixed schema across documents — one user document can have a phone field while the next one does not.

{
  "_id": "u_1042",
  "email": "[email protected]",
  "addresses": [
    { "type": "home", "city": "Lisbon" },
    { "type": "work", "city": "Porto" }
  ]
}

The win here is that nested, flexible data (like those two addresses) lives inside one document, so you often do not need joins. The trade-off is that the application now has to keep data consistent, because the database does fewer checks for you. The most popular document database is MongoDB.

When to use document stores: When your data is naturally nested and read as a whole, when the shape changes often during early development, or when you genuinely do not know the schema yet (e.g. flexible event logs or content). When NOT to: When you have lots of relationships and need guaranteed consistency across them — that is exactly what SQL does better.

Key-value stores

A key-value store is the simplest model: you store a value under a key, like a giant dictionary. You ask for a key, you get the value back — extremely fast. These are usually held in memory (RAM) for speed, which is why Redis is the classic example.

redis-cli SET session:abc123 "user_1042"
redis-cli GET session:abc123

Output:

OK
"user_1042"

Key-value stores are not usually your main database. They sit alongside it as a cache (a fast temporary copy of data), a session store, or a rate-limiter.

When to use key-value: Caching, sessions, leaderboards, queues, and anything that needs sub-millisecond lookups. When NOT to: As your only store for important data you cannot afford to lose — though Redis can persist to disk, its strength is speed, not complex queries.

SQL vs NoSQL — side by side

Aspect	SQL (relational)	NoSQL (document / key-value)
Data shape	Tables: rows and columns	Documents (JSON) or key-value pairs
Schema	Fixed, defined up front	Flexible / schema-less
Relationships	Joins across tables	Nested data; joins are limited or manual
Consistency	Strong (ACID transactions)	Often “eventual”; varies by product
Query language	SQL (standard)	Product-specific APIs / query syntax
Scaling style	Usually scale up (bigger server); read replicas	Often built to scale out (more servers)
Best for	Structured, related data; money; reporting	Nested/flexible data; caching; huge scale
Examples here	PostgreSQL, MySQL	MongoDB (document), Redis (key-value)

Common myth to ignore: “NoSQL is faster than SQL.” It is not, in general. A well-indexed PostgreSQL table handles millions of rows comfortably. NoSQL trades the database’s safety guarantees for flexibility or horizontal scale — it does not magically make every query quicker.

Mapping the databases in these docs

The databases covered in this DevOps section fall neatly into the categories above:

Database	Category	Typical role
PostgreSQL	SQL (relational)	Powerful default for most apps; strong correctness and rich features
MySQL	SQL (relational)	Very popular relational database; common in web and WordPress stacks
MongoDB	NoSQL (document)	Flexible JSON documents; good for evolving or nested data
Redis	NoSQL (key-value)	In-memory cache, sessions, queues — speed alongside a main database

A very common real-world setup is not “SQL or NoSQL” but both: PostgreSQL (or MySQL) as the source of truth for your core data, with Redis in front of it as a cache. This is called polyglot persistence — using the right tool for each job.

How to decide

Ask yourself these questions in order:

Does my data have relationships and need to stay correct (money, counts, bookings)? → Use SQL. This covers most applications.
Is my data deeply nested, read as one blob, and changing shape often? → A document store like MongoDB may fit.
Do I need a fast cache or session/queue layer next to my main database? → Add a key-value store like Redis.
Am I genuinely unsure? → Start with PostgreSQL. You will rarely regret it, and it even stores JSON well via its jsonb type if you need flexibility later.

Best Practices

Default to SQL (PostgreSQL or MySQL) unless you have a concrete, measured reason to choose NoSQL — flexibility you do not yet need is not a reason.
Do not throw away ACID for write-heavy financial or inventory data; the guarantees prevent expensive bugs.
Use Redis as a cache, not a database of record — treat anything in it as data you could lose and rebuild from your main store.
Reach for a document store only when your data is naturally nested and your access pattern reads whole documents at once.
Index every column or field you filter or join on, in both SQL and NoSQL — missing indexes, not the database type, cause most “slow database” complaints.
Combine technologies on purpose (polyglot persistence): a relational main database plus Redis caching is a proven, boring, reliable pattern.
Avoid resume-driven choices — pick the database that fits the problem, not the one that sounds impressive.