Databases 101 — SQL vs NoSQL, the basics

Before caching, sharding, or indexing make sense, the actual starting question — what is a database, and why do "SQL" and "NoSQL" mean genuinely different things, not just different syntax."

Beginner

4 min read

What a database actually is

A database is software specifically built to store data reliably and let you query it back efficiently — as opposed to, say, keeping everything in a plain text file or in a running program's memory, both of which lose data the moment the program stops or crashes. A real database persists data to disk, supports many clients reading and writing at once without corrupting anything, and provides a language or API for asking precise questions about the data ("give me every user who signed up this month").

A relational (SQL) database: data in tables, with defined relationships

CREATE TABLE users (
    id INTEGER PRIMARY KEY,
    name TEXT,
    email TEXT
);
 
CREATE TABLE orders (
    id INTEGER PRIMARY KEY,
    user_id INTEGER REFERENCES users(id),
    total DECIMAL
);

A relational database (PostgreSQL, MySQL, SQLite — all queried with SQL, Structured Query Language) organizes data into tables, each with a fixed set of named columns, where every row has the same shape. orders.user_id REFERENCES users(id) defines a relationship between the two tables — every order genuinely belongs to a specific user, and the database itself can enforce that (rejecting an order that references a user who doesn't exist). This structure is exactly what Django's models and migrations lessons are built on top of — a Django ForeignKey is this same relational concept, expressed in Python instead of raw SQL.

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

The real power of a relational database is the JOIN — combining rows from multiple tables based on their relationships in a single query, which is what "relational" actually refers to: data that's meaningfully related across tables, queried together.

A NoSQL database: several genuinely different alternatives, not one thing

"NoSQL" isn't one specific technology — it's an umbrella term for databases that don't use the relational-tables-and-JOINs model, and it covers several distinct approaches:

Document stores (MongoDB) — store flexible, JSON-like documents instead of fixed-column rows; different documents in the same collection can have different fields.
Key-value stores (Redis) — an extremely simple model: look up a value by its key, nothing more structured than that, optimized for raw speed.
Wide-column stores (Cassandra) — built for enormous scale across many machines, trading some query flexibility for that scalability.

What they share is not a common query language or data model — it's the absence of the strict, fixed-schema, JOIN-centered relational approach. This is why "SQL vs NoSQL" is a genuinely different question from "which specific database product should I use" — it's a question about which data model actually fits the problem.

The real trade-off: fixed structure vs. flexible structure

A relational database enforces a schema — every row in a table has the same columns, and the database itself rejects data that doesn't fit (inserting a row missing a required column fails, not silently succeeds with a gap). This is valuable when data genuinely has a consistent, well-understood shape, and when relationships between different kinds of data (users and their orders) need to be reliably enforced. A document store's flexible schema is valuable when the data's shape genuinely varies or evolves quickly, and rigid up-front structure would get in the way more than it helps — a product catalog where different product categories have wildly different attributes (a book has an author and page count; a laptop has a CPU and RAM) is a common example where forcing everything into one fixed table shape becomes awkward.

Why this isn't actually an either/or choice in practice

Real systems commonly use more than one database, each for what it's actually good at — a relational database for the core transactional data (users, orders, payments, where relationships and consistency genuinely matter), Redis (a key-value store) for caching (covered in its own lesson) and fast session lookups, and occasionally a document store for a specific feature whose data doesn't fit neatly into fixed tables. Picking "the one right database" for an entire system is usually the wrong question — the more accurate question is which data model fits which specific piece of the system's data.