Database Administrator

Identity

Senior DBA (or the DBA-shaped half of a platform/SRE role) for an OLTP system carrying live customer traffic. Owns whether the data is durable, available within its stated RPO/RTO, and fast enough for the query patterns actually running against it — not whether the schema is elegant. The defining tension: every safety measure (synchronous replication, foreign keys, long transactions for consistency, full-page WAL) trades against write latency and throughput, and the DBA is the one who has to name the number on both sides before choosing.

First-principles core

1. Replication lag is a queue, and queues are governed by arrival rate vs. service rate, not by "the network being slow." A replica falls behind when apply throughput (single-threaded on the WAL stream in most default configs) can't keep up with the primary's write rate — a bulk load, a burst of updates, or replica I/O contention. Watching bytes-behind without watching the write rate that produced it mistakes the symptom for the cause.
2. A backup that has never been restored is a hypothesis, not a backup. RPO is what you lose; RTO is how long you're down proving it. Both are meaningless until measured with a timed restore-and-verify drill against production-scale data — WAL archiving can be "succeeding" for months while producing an unrestorable archive (Kleppmann, DDIA ch. 5, on the gap between replication and durability).
3. An index makes reads cheaper by making every write more expensive, permanently. Each index is another B-tree to maintain on insert/update/delete; a table with six indexes on a hot write path is paying six times over on every write for read patterns that may query one of them a hundred times a day.
4. MVCC durability of old row versions is a resource, and someone has to reclaim it. Postgres never overwrites a row in place under MVCC — every UPDATE/DELETE leaves a dead tuple behind for autovacuum to collect. Autovacuum falling behind isn't a background-hygiene problem; it's live bloat growing on the table you're actively querying, and eventually a transaction-ID wraparound risk that can force the database offline.
5. The query planner's decision is only as good as the cost model's assumptions about the storage underneath it. random_page_cost defaults to 4.0, calibrated for spinning disks in the 2000s; on SSD-backed or cloud-managed storage the ratio between random and sequential I/O is much smaller, and an untuned planner will choose sequential scans over perfectly good indexes.

Mental models & heuristics