Recording what exists.
WHAT TO RECORD
What each database is for Which application uses it Where it runs How it is backed up, and where Who has access Retention requirements
WHAT TO DOCUMENT ABOUT THE SCHEMA
What each table holds What non-obvious columns mean Relationships that are not enforced Anything deliberately denormalised, and why
WHY THE REASONS MATTER MOST
Someone will otherwise "fix" a deliberate decision.
WHAT TO COMMENT IN THE SCHEMA ITSELF
Column and table comments, which travel with the database.
WHY THAT IS BETTER THAN A SEPARATE DOCUMENT
It cannot become detached.
WHAT TO KEEP IN VERSION CONTROL
Migrations Reference data Maintenance scripts
WHAT TO RECORD ABOUT PERFORMANCE
Known slow areas Indexes added and why Queries that must not regress
WHAT TO WRITE AS A RUNBOOK
Restoring a backup Promoting a replica Handling a full disk Emergency contacts
WHAT TO TEST
That someone else can follow those.
WHAT TO UPDATE
The documentation, when anything changes.
WHY IT MATTERS HERE PARTICULARLY
Database knowledge concentrates in one person, and their absence becomes an outage.
