A database isn't one single piece of software doing one job — it's a small stack of distinct layers, each responsible for a different part of turning your request into an answer. This chapter is a bird's-eye map of those layers before the rest of this course zooms into each one.
Why This Matters
Every chapter from here on lives inside one specific layer of this stack — SQL and querying live in one layer, indexes and storage live in another, and knowing the overall shape of the system now means you'll always be able to place a new idea in context, instead of collecting isolated facts with no sense of how they fit together.
Core Concept
At a high level, a relational database system has three broad layers. At the top, a Client — your application, or a tool you use directly — sends a request, usually a query written in SQL. In the middle, the database engine's Query Processor interprets that request, checks it's valid, and works out the most efficient way to fulfill it. At the bottom, the Storage Engine is responsible for actually reading and writing the data on disk, and making sure it stays safe and consistent even if something goes wrong mid-operation.
Deep Dive
- The client layer is whatever sends requests to the database — this could be your own application's code, a command-line tool, or a graphical database client. It doesn't need to know anything about how the data is physically stored.
- The query processing layer takes a request written in SQL, checks that it makes sense (correct syntax, real tables and columns), decides on an execution plan — the specific steps it'll take to answer the request efficiently — and carries that plan out.
- The storage layer manages how data is actually written to and read from disk, in a way that survives crashes and stays consistent under concurrent access. You'll meet this layer properly much later in this course, under Storage Engine Internals — for now, it's enough to know it exists as a distinct responsibility, separate from query processing.
Visual Diagram
THE THREE LAYERS OF A RELATIONAL DATABASE
Client
your application or a database tool
Query Processor
checks it, plans how to answer it
Storage Engine
manages data safely on disk
Production Perspective
When a query runs slower than expected in a real system, experienced engineers instinctively ask which layer the problem is actually in — is the query itself poorly written (a query-processing problem), or is the underlying data access genuinely slow (a storage problem)? Knowing this three-layer shape is what makes that question answerable at all, instead of guessing.
Common Mistakes
Treating "the database is slow" as one single, undiagnosable problem.
Why: A slowdown in the query-processing layer, like a poorly written query, has a completely different fix than a slowdown in the storage layer, like a missing index or disk contention — without knowing which layer is involved, it's hard to even start diagnosing.
Fix: Learn to ask which layer a symptom belongs to before trying to fix it — you'll build the specific tools for this later in the course.
Interview Questions
What are the three broad layers of a relational database system described in this chapter?
The client (sends requests), the query processor (checks and plans how to answer them), and the storage engine (reads and writes the actual data safely).
Why does it help to separate the query-processing layer from the storage layer, rather than treating the database as one single black box?
It lets you reason about performance and correctness problems separately — a badly written query is a query-processing problem, while a slow disk or missing index is a storage problem, and they need different fixes.
Best Practices
Do
✓Think of a database as layers with distinct jobs, not one single black box.
✓When something is slow or wrong, ask which layer is actually responsible before trying to fix it.
✓Build a mental map now that you can attach later, more detailed chapters to.
Don't
✗Don't assume every database problem has the same kind of fix — different layers fail in different ways.
✗Don't skip building a rough mental model of the whole system just because you haven't learned the details of each layer yet.
Chapter Summary
A relational database is a stack of distinct layers — a client that sends requests, a query processor that interprets and plans how to answer them, and a storage engine that safely manages the actual data. Every remaining chapter in this course fits into one of these layers, and this map is what will let you place each new idea in context as you go. With the big picture in place, the next section moves from "what is a database" to the actual vocabulary of the relational model itself: tables, rows, columns, and more.