An illustrated miniature freight depot glowing with lamplight, with a teal locomotive and colourful cargo crates
A tiny database adventure

Query
Depot.

120 crates. One impatient train.
A good index knows where to look.

Welcome to the night shift.

Choose a dispatch slip, pick an index, then run the search. Can you spare the clerk a walk through the entire yard?

01 / dispatch slip

02 / choose your index
Index route

03 / watch the work

Every square is one cargo record.

120
crates
UntouchedInspectedFound · underlined
0crates inspected
0matches loaded
—walks spared
The signal is yours.

Start with “No index” to see the long way round. Then try a shortcut on the same dispatch slip.

All four dispatches explored

Night shift, neatly shipped.

Some searches need a better index. Some simply need the whole yard. Knowing the difference is the job.

Crate inspections only, not index-navigation steps or real execution time. This is a simplified read-only index model, not a live SQL database.

For the curious: what is the train actually teaching?

An index is an extra, ordered directory of column values and record locations. It helps the database avoid reading irrelevant rows. Here, each index really is built from the cargo records in your browser; the search uses its directory to select the candidate crates.

A composite index on (customer, status) groups by customer first, then status. It can narrow a search for both fields, or for customer alone. A status-only search cannot use that leading customer key to pick one contiguous range. Real databases sometimes have additional strategies, including skip scans, which this toy deliberately leaves out.

Indexes take space and must be maintained when records change. More indexes are not automatically better. We count candidate cargo records here, not tree navigation, page reads, caching, or other costs a real query planner considers.