A Bloom filter answers 'have I seen this before?' using a fraction of the memory a real set would need — by allowing one specific kind of wrong answer. It's the data structure behind databases skipping disk reads they don't need.
Every database picks one of two ways to put data on disk. The choice between B-trees and LSM-trees is really a choice about whether you optimize for reads or writes — and you can't have both for free.
Postgres never updates a row — it writes a new version and lets old transactions keep seeing the old one. Multiversion concurrency is why reads don't block writes, why VACUUM exists, and why 'the database is bloated' is a real sentence.
An index is a sorted structure with physical properties, not a magic 'go faster' flag. Leftmost prefixes, covering indexes, selectivity, and the honest reasons the planner chose a sequential scan over the index you lovingly created.
Every database, filesystem, and message broker converges on the same move: append the intention to a sequential log, fsync, then update the real structures whenever. WAL is one idea wearing a dozen names — and its failure modes repeat too.
SQL says what, the planner decides how — by estimating row counts through a chain of guesses and picking the cheapest of thousands of plans. When the estimate is wrong by 1000x, so is the plan. Reading EXPLAIN is learning to audit those guesses.
Databases read disk through fixed-size pages cached in a buffer pool they manage themselves — duplicating what the kernel's page cache already does. The reasons why (eviction control, WAL ordering, O_DIRECT) are a masterclass in when to bypass the OS.