To decide whether a new transaction is valid, a node does not search the whole blockchain. It looks things up in one table: the UTXO set, the list of every coin that exists and has not been spent.
What is stored
Each entry is keyed by its outpoint (txid + output index) and holds the amount, the locking script, the height of the block that created it, and a flag if it came from a coinbase transaction. In Bitcoin Core, this database is called the chainstate and lives in LevelDB in the chainstate folder.
How blocks change it
When a block connects, its spent inputs are removed and its new outputs are added. Bitcoin Core also saves "undo" data for each block, so if a reorganisation removes a block, the spent coins can be put back.
Speed and memory
Lookups happen for every input of every transaction, so speed matters. Bitcoin Core caches coins in RAM, controlled by -dbcache. Version 31.0 raised the default from 450 MiB to 1,024 MiB on systems with at least 4,096 MiB of RAM. A larger cache can greatly speed up the first sync.
Size
The UTXO set is much smaller than the full chain, but it is still several gigabytes on disk, and every full node must keep all of it. Every new output adds to it until spent, so creating many tiny outputs has a cost for everyone. This is one reason for dust limits.
Pruning
A pruned node can delete old block files, keeping as little as 550 MiB of them, but it must keep the full chainstate. Pruned nodes still validate everything.
Snapshots
Bitcoin Core can export the set with dumptxoutset. With assumeutxo, a new node can load such a snapshot if its hash matches one written into the source code, then check the history in the background. Read about it in Initial block download.