How Databases Work: The Big Picture

Build the mental model

This platform already has deep, hands-on courses for working databases: SQL for query syntax, PostgreSQL for a full production-grade relational system, MongoDB for a leading document database, and Redis for an in-memory data store. Those courses teach you to type real commands against a real system.

How Databases Work sits above all four. Before you write a single SELECT statement or a single insert command, you need a framework-neutral mental model: what a database actually is, what a table, key, relationship, and transaction mean as concepts, and how the pieces fit together no matter which product you eventually pick.

You'll also get a fair, honest comparison of the SQL versus NoSQL landscape later in this course — not a verdict that one is "better," but a clear picture of the tradeoffs each family makes, so a technology choice becomes a reasoned decision instead of a guess.

The master mental model

User -> Frontend -> Backend/API -> Database -> Data. A user acts in a frontend, the frontend asks a backend/API to do something, the backend talks to the database, and the database returns or stores data.

Don't give the frontend database credentials

The frontend should never hold privileged database credentials directly, because anything shipped to a browser or mobile app can be extracted. A safer alternative is Frontend -> Secure Data Access Layer/BaaS -> Database, where that middle layer enforces authorization policies before any data moves.

Database: A system that stores, organizes, and lets you reliably retrieve and update data, usually shared by many parts of an application at once.

DBMS: Database Management System — the actual software (like PostgreSQL, MongoDB, or Redis) that implements a database engine: storage, querying, concurrency, and reliability guarantees.

text

THE MASTER MENTAL MODEL
-----------------------
THE MASTER MENTAL MODEL
------------------------
  User
   |
   v
Frontend   (web app / mobile app)
   |
   v
Backend/API   (server logic + interface)
   |
   v
Database   (stores + organizes data)
   |
   v
  Data

SAFER ALTERNATIVE (no DB credentials in the frontend)
---------------------------------------------------------
  User -> Frontend -> Secure Data Access Layer/BaaS -> DB
                       (enforces authorization policies)

Connect it to a real scenario

As you go through this course, keep translating each concept back to something concrete you've touched, even if you haven't taken any hands-on course yet: a user profile, a shopping cart, a chat message. The goal is a shared vocabulary you can carry into SQL, PostgreSQL, MongoDB, or Redis without relearning the basics each time.

If you already know one product well, don't skip this course — the value here is the connective tissue product-specific courses don't teach: why a relational table and a MongoDB document represent the same idea differently, or why PostgreSQL transactions and Redis pipelines solve related but different problems.

Try the self-check code

Run the code below to check which of your finished courses matter, and see which chapters of this course still carry genuinely new material for you.

This course teaches the framework-neutral layer above any specific database product
The master mental model: User -> Frontend -> Backend/API -> Database -> Data
Frontends should never hold privileged database credentials directly

Try the working example

javascript

function recommendNewChapters(priorCourses = {}) {
  const {
    completedSQL = false,
    completedPostgreSQL = false,
    completedMongoDB = false,
    completedRedis = false,
  } = priorCourses;

  const knowsRelational = completedSQL || completedPostgreSQL;
  const knowsNonRelational = completedMongoDB || completedRedis;
  const knowsAnyProduct = knowsRelational || knowsNonRelational;

  const chapters = [
    { name: "Basic", isNew: () => true },
    { name: "SQL vs NoSQL Landscape", isNew: () => !(knowsRelational && knowsNonRelational) },
    { name: "Transactions & Concurrency Concepts", isNew: () => !(completedPostgreSQL && completedRedis) },
    { name: "Scaling & Performance Concepts", isNew: () => !knowsAnyProduct || !(knowsRelational && knowsNonRelational) },
  ];

  return chapters.filter((chapter) => chapter.isNew()).map((chapter) => chapter.name);
}

console.log("Brand-new learner:", recommendNewChapters({}));
console.log("Finished SQL only:", recommendNewChapters({ completedSQL: true }));
console.log(
  "Finished all four:",
  recommendNewChapters({
    completedSQL: true,
    completedPostgreSQL: true,
    completedMongoDB: true,
    completedRedis: true,
  })
);

You should see

Brand-new learner: [ 'Basic', 'SQL vs NoSQL Landscape', 'Transactions & Concurrency Concepts', 'Scaling & Performance Concepts' ]
Finished SQL only: [ 'Basic', 'SQL vs NoSQL Landscape', 'Transactions & Concurrency Concepts', 'Scaling & Performance Concepts' ]
Finished all four: [ 'Basic' ]

5-minute try-it

Using recommendNewChapters's logic as inspiration, write down which chapters you'd genuinely still need if you had completed the SQL and MongoDB courses but not PostgreSQL or Redis.

One important caution

Treating this course as a shortcut past SQL/PostgreSQL/MongoDB/Redis — it teaches concepts, not syntax you can run in production

Assuming NoSQL vs SQL is a 'winner' debate rather than a tradeoff between different guarantees for different problems

Wikipedia: Database — How Databases Work