GARAGE Model: The Query Execution Model
A visual mental model for understanding how a database query travels through the server — from parsing and optimization to execution, locking, and storage.
Your First Ferrari 🏎️
You ordered your first Ferrari.
Red paint. Leather seats. Every detail picked by you.
But the Ferrari is not in your driveway yet.
The dealer has to turn your choices into an actual order, then send that order into the factory system.
So the dealer enters:
UPDATE ferrari_inventory
SET cars_available = cars_available - 1
WHERE model = 'LaFerrari';
One LaFerrari is no longer available for the next buyer.
The car is not built yet.
But the order has crossed into the system.
To you, it is the start of a dream car.
To the database, it is the start of a query.
The Client and the Server
Before the order can travel, we need two sides.
A client is the side that asks.
A server is the side that answers.
In our Ferrari story, the dealership order system is the client.
The database is the server.
The dealership system sends the order as SQL:
UPDATE ferrari_inventory
SET cars_available = cars_available - 1
WHERE model = 'LaFerrari';The database server receives it.
At this point, the order has only reached the factory window.
The dealer has handed the order over.
Now the factory path begins.
Inside the database, that path is the GARAGE.
Inside the GARAGE Model
The database does not simply “subtract one car.”
It takes the Ferrari order through the GARAGE.
First, the order enters.
Then it is understood.
Then the best build plan is created.
Then the plan is followed.
Then the sale is protected.
Finally, the real inventory record is updated.
That path is the GARAGE:
Gate → Analyzer → Route Planner → Autopilot → Guard → Engine Vault
G — Gate
Front Gate
Connection / client communication
The query enters the database server.
G = Gate, where the order enters
Every Ferrari build starts at the factory window.
The dealer sends the order into the system as a SQL query:
UPDATE ferrari_inventory
SET cars_available = cars_available - 1
WHERE model = 'LaFerrari';
In database lingo, this factory window is the transport subsystem.
The transport subsystem handles communication such as:
- Client communication — receiving queries from applications and sending results back.
- Cluster communication — talking to other database nodes if the database is distributed.
So in our GARAGE mnemonic:
G = Gate = transport for communication
A = Analyzer, where the order is understood
The Gate passes the order to the Analyzer.
The Analyzer reads the SQL and checks what the order actually means.
It asks questions like:
- Is this valid SQL?
- Does the ferrari_inventory table exist?
- Does the cars_available column exist?
- Is this an update, a read, or something else?
The Analyzer does not decide the best way to run the order yet.
It turns the raw SQL into something the database can reason about.
A = Analyzer = understand the order
R = Route Planner
Once the order is understood, it moves to the Route Planner.
In database lingo, this is the query optimizer.
The optimizer chooses the best way to carry out the order.
It may consider:
- available indexes
- table statistics
- data placement
- possible execution paths
There may be many valid ways to update the same LaFerrari record.
The Route Planner picks the best plan it can find.
The result is an execution plan.
R = Route Planner = choose the best execution plan
A = Autopilot, where the plan is followed
The best build plan now moves to the Autopilot.
In database lingo, this is often called the execution engine.
The execution engine follows the plan step by step.
For our Ferrari order, it may need to:
- find the matching LaFerrari record
- reduce cars_available
- collect the result
- coordinate work across nodes if the data is remote
The Autopilot follows the planned optimal route.
A = Autopilot = follow the execution plan
Before the Guard: what is a transaction?
Before the Guard makes sense, we need one word: transaction.
Think of a family crossing a busy road with young children.
If everyone keeps moving safely, the family reaches the other side together.
But if one child starts falling behind, the family retreats together and tries again later.
For a successful crossing:
Either everybody crosses together, or no one crosses.
A transaction is a group of database operations treated as one logical unit. The operations should either succeed together or fail together.
For our Ferrari sale, the database needs to perform several related steps:
- reduce cars_available
- record the sale
- update the customer order
If all steps succeed, the transaction can commit.
If something fails halfway, the transaction will roll back.
A transaction prevents the database from being stuck in a halfway-across-the-road state.
Now the Guard can do its job.
G = Guard, where the sale is protected
Now imagine there is only one Tailor Made red finish left for this production batch.
But two buyers choose it at almost the same time.
Without protection, both orders might try to claim the same rare finish.
This is where the Guard comes in.
Inside the storage engine, the Guard is mainly handled by the lock manager and the transaction manager.
The lock manager places a temporary “Do Not Touch” sign on the Tailor Made finish record while your order is being processed.
The transaction manager makes sure the full sale moves as one unit.
Either the finish is reserved, the sale is recorded, and the customer order is updated together, or they roll back together.
G = Guard = transaction manager + lock manager for concurrency control
E = Engine Vault, where the Ferrari gets its engine
Now the Ferrari build is almost complete.
The paint, leather, and wheels are ready.
But the car is not alive until the engine goes in.
This is the Engine Vault, where the database stores, retrieves, caches, and recovers the real Ferrari order and inventory data.
Inside the Engine Vault are three important components.
Access Methods
Now the dealer needs to find the exact engine meant for your LaFerrari.
The access methods help the database locate data quickly using storage structures like B-Trees or LSM Trees.
Without them, the dealer would search one shelf at a time, taking forever to get your LaFerrari ready.
Buffer Manager
The buffer manager keeps frequently used data pages in memory for faster access.
Think of it like keeping the Ferrari engine ready on a cart near the assembly line.
When the engine is already nearby, it can be rolled over and installed quickly instead of being pulled from deep storage every time.
Recovery Manager
The recovery manager keeps an operation log so the database can recover after failures.
Think of it like documenting every step of the Ferrari engine installation.
If the lights go out halfway through, the dealership does not have to guess what happened.
It can check the log, keep the completed work that was safely finished, and undo anything left half-done instead of leaving your LaFerrari half-built.
E = Engine Vault = locate, stage, and recover
The GARAGE Model (Save This)
LaFerrari Driver Notes
Client
The side that asks. In our story, this is the dealership's inventory application sending the request.
Client. The side that asks. In our story, this is the dealership's inventory application sending the request.
Quiz
86% of people love quizzes after learning. Are you one of them?
Question text
Quiz complete