Storage formats and database families, plus the working knowledge a relational system actually demands - schema design, indexes, plans, transactions, and the layers your application puts in front of them.
Storing every fact exactly once, so it can only be wrong in one place. The three normal forms that matter, the anomalies they prevent, and when copying data is the requirement rather than the mistake.
Read it →The layer that turns rows into objects and back. What it genuinely solves, what it hides, and the habits that separate a fast data layer from one issuing fifty-one queries per page.
Read it →The cache of open connections between your application and the database. Why it runs out long before the database does, and what that timeout message is actually telling you.
Read it →Storage that answers "what is most similar to this?" instead of "what matches this?". Embeddings, approximate nearest-neighbour search, and whether you need a separate database at all.
Read it →The difference between reading three pages and reading eighty thousand. What a B-tree actually stores, why the engine ignores the index you just built, and what every index costs on the write side.
Read it →Your SQL is a description of a result, not a set of instructions. The plan is the program the optimizer wrote to satisfy it - and reading one is the difference between tuning a query and guessing at it.
Read it →A group of statements the database treats as one indivisible unit - and the locks, isolation levels, and deadlocks that come attached to the guarantee.
Read it →The single file that captures the entire schema of a SQL Server database - tables, views, procedures, permissions - in a form a deployment tool can diff, version, and apply.
Read it →A family of databases that step away from the relational model - key-value, document, wide-column, and graph - and the trade-offs you accept in exchange.
Read it →No cards match that combination.