Database Index
A secondary structure that lets the engine find rows without scanning, trading write cost and storage for read speed.
An index turns a full scan into a lookup, which is the difference between a query that takes seconds and one that takes microseconds. Every index also has to be updated on every write to the indexed columns, so a table with twelve indexes has a write path twelve times more expensive than its unindexed self.
Things worth knowing at architecture level: a composite index is usable only for a left-to-right prefix of its columns, so column order is a design decision. A covering index that contains every column the query needs avoids touching the table at all. Selectivity decides usefulness — an index on a boolean column is usually ignored.
Storage engine matters too. B-trees are read-optimised and pay on random writes; LSM trees are write-optimised, absorbing writes sequentially and paying later in compaction. That is why write-heavy stores tend to use the latter.