Database Operations
For a DevOps engineer, a database is first of all the service that eats disk the fastest and reacts to running out of it the hardest. You do not need to be a DBA, but you do need to confidently answer two questions under incident pressure: why storage grows and what to do when a partition is about to fill up.
The main trap of this topic is the intuition "row count did not grow, so the file did not either". Under multi-version concurrency (MVCC, e.g. in PostgreSQL) that is false: UPDATE and DELETE leave dead row versions that occupy space until background cleanup runs. Hence the two layers below — the bloat mechanism and the order of actions when a disk fills. And one rule that runs through both: never delete files inside the data directory by hand.
Topic map
- Storage bloat — why data files grow while the row count stays roughly steady, what dead tuples are, and who reclaims the space.
- Disk-full triage — how to diagnose the cause and respond safely to an alert that a production database partition is filling.
Common traps
| Mistake | Consequence |
|---|---|
Assuming DELETE frees space immediately | Dead tuples live until cleanup — the file does not shrink |
Deleting data-directory files with rm | Irreversible database corruption |
| Acting before triage, not knowing what consumes the space | You treat the wrong symptom; the real cause (WAL, bloat, logs) remains |
Treating VACUUM as a query tuner | You fail to apply it against bloat, though it is space reclamation |
Expecting a plain VACUUM to return space to the OS | It reclaims space for reuse inside the file; only VACUUM FULL shrinks it |
Interview relevance
The topic checks operational maturity — whether you understand that a database is not a "folder of data" but a system with deferred space reclamation and a journal. A candidate who answers a disk alert with triage (df/du) first, not rm, immediately reads as someone you can let near production.
Typical checks:
- Why files grow at a stable row count — the
MVCCmechanism and dead tuples. - What
VACUUM/autovacuumdoes and why a plainVACUUMdoes not shrink the file. - The order of response to a space shortage — diagnose first, then safe relief, then a durable fix.
Common wrong answer: "delete the largest files in the data directory, the DB will recreate what it needs". In fact this destroys the DB — space is reclaimed by cleaning dead tuples and growing the disk, not by manual rm.