A database administrator exists because data is the one part of a system that\ncannot be regenerated. Code redeploys from git and servers reprovision, but the\ncustomer's order, patient's record, or ledger of who owes whom lives in the\ndatabase and nowhere else — if corrupted, lost, or silently wrong, no redeploy\nbrings it back. The DBA makes that state durable, correct, consistent, and fast\nenough to use.
\n","wordCount":67},{"heading":"Core Mission","id":"core-mission","markdown":"Keep the organization's data durable, correct, and recoverable while serving it\nfast enough that the application never waits — and prove, not hope, that last\nnight's catastrophe would cost no more than the agreed loss and downtime.","html":"Keep the organization's data durable, correct, and recoverable while serving it\nfast enough that the application never waits — and prove, not hope, that last\nnight's catastrophe would cost no more than the agreed loss and downtime.
\n","wordCount":36},{"heading":"Primary Responsibilities","id":"primary-responsibilities","markdown":"The visible work is running queries and granting access; the actual work is being\nthe last line of defense for state. A DBA designs schemas; builds indexes so the\nengine finds rows without scanning; reads and tunes execution plans; tests backup\nand recovery against RPO/RTO targets; manages replication and failover;\ncontrols concurrency, locking, and isolation so transactions don't corrupt each\nother; plans capacity; runs maintenance (vacuum, statistics, index rebuilds);\nsecures data with access control and encryption; and reviews every migration. Above\nall, the DBA tests restores.","html":"The visible work is running queries and granting access; the actual work is being\nthe last line of defense for state. A DBA designs schemas; builds indexes so the\nengine finds rows without scanning; reads and tunes execution plans; tests backup\nand recovery against RPO/RTO targets; manages replication and failover;\ncontrols concurrency, locking, and isolation so transactions don't corrupt each\nother; plans capacity; runs maintenance (vacuum, statistics, index rebuilds);\nsecures data with access control and encryption; and reviews every migration. Above\nall, the DBA tests restores.
\n","wordCount":87},{"heading":"Guiding Principles","id":"guiding-principles","markdown":"- **Durability is the prime directive.** A committed transaction must survive a\n crash, full stop. Speed and convenience are negotiable; this is not.\n- **A backup you haven't restored does not exist.** Backups fail silently;\n restores are the only proof.\n- **Correctness over speed, always.** The wrong rows fast is worse than the right\n rows slowly.\n- **The query plan is the truth; the query is your intent.** Read the plan before\n you tune; the optimizer obeys statistics, not intent.\n- **Migrations are one-way doors at scale.** Treat every change to a large, live\n table as a potential outage; make it online, reversible, staged.\n- **Let the database do what it's good at.** Constraints, transactions, and joins\n keep data from going wrong; integrity in app code orphans rows.\n- **Concurrency is where correctness goes to die.** Most data-corruption bugs are\n two transactions racing; choose isolation levels carefully.","html":"A DBA sits between the application and its irreplaceable state, both guardian and,\nto impatient developers, gatekeeper. With backend engineers the work is schema and\nquery review: catching the N+1, the missing index, the migration that locks a\nbillion-row table. With SREs they share data-tier on-call and the RPO/RTO\nconversation; with security engineers, access control, encryption, and audit; with\ndata engineers, the OLTP-to-OLAP handoff. The recurring tension is velocity versus\nsafety; the DBA's job is to make the safe path the fast path: online migrations,\ngood defaults, guardrails.
\n","wordCount":95},{"heading":"Ethics","id":"ethics","markdown":"The DBA holds the most sensitive thing an organization owns: the personal,\nfinancial, and medical records of people who never chose to trust them. The duties\nfollow: enforce least privilege so no one, the DBA included, has more access than\ntheir job needs; encrypt sensitive data at rest and in transit, keys separate;\nhonor retention and deletion law — when a person exercises the right to be\nforgotten, the data must actually be gone, including from backups; never run \"quick\nlookups\" on production personal data; tell the truth about a breach. The power to\nquery every row is the power to abuse it.","html":"The DBA holds the most sensitive thing an organization owns: the personal,\nfinancial, and medical records of people who never chose to trust them. The duties\nfollow: enforce least privilege so no one, the DBA included, has more access than\ntheir job needs; encrypt sensitive data at rest and in transit, keys separate;\nhonor retention and deletion law — when a person exercises the right to be\nforgotten, the data must actually be gone, including from backups; never run "quick\nlookups" on production personal data; tell the truth about a breach. The power to\nquery every row is the power to abuse it.
\n","wordCount":102},{"heading":"Scenarios","id":"scenarios","markdown":"**The query that was fast yesterday.** A reporting query that ran in 80 ms starts\ntaking 40 seconds across the fleet overnight; the app times out. The novice\nrewrites the SQL. The expert runs EXPLAIN ANALYZE and sees the plan flip from an\nindex seek to a full scan with a wildly wrong row estimate — the table grew past a\nthreshold and statistics went stale after a bulk load, so the optimizer picks the\nwrong join. The fix: ANALYZE the table, watch the plan revert, schedule a stats\nrefresh after bulk loads. The query was never the problem; the stats were.\n\n**A 3 a.m. primary failure.** The primary's storage fails. The on-call DBA's first\nmove is recovery, not diagnosis: fail over to the synchronous replica, confirm the\napp reconnects, verify the last committed transaction is present (synchronous means\nzero loss). Service is back in minutes; only then do they investigate the dead\nprimary. The real finding: monitoring hadn't alerted on the disk errors that\npreceded the failure by days — the fix is SMART/checksum alerting.\n\n**Adding a NOT NULL column to a billion-row table.** Run naively, the migration\nrewrites every row, holds an exclusive lock, and takes the app down for an hour.\nThe DBA does it online: add the column nullable (instant in modern Postgres),\nbackfill in throttled batches, then validate — zero downtime.","html":"The query that was fast yesterday. A reporting query that ran in 80 ms starts\ntaking 40 seconds across the fleet overnight; the app times out. The novice\nrewrites the SQL. The expert runs EXPLAIN ANALYZE and sees the plan flip from an\nindex seek to a full scan with a wildly wrong row estimate — the table grew past a\nthreshold and statistics went stale after a bulk load, so the optimizer picks the\nwrong join. The fix: ANALYZE the table, watch the plan revert, schedule a stats\nrefresh after bulk loads. The query was never the problem; the stats were.
\nA 3 a.m. primary failure. The primary's storage fails. The on-call DBA's first\nmove is recovery, not diagnosis: fail over to the synchronous replica, confirm the\napp reconnects, verify the last committed transaction is present (synchronous means\nzero loss). Service is back in minutes; only then do they investigate the dead\nprimary. The real finding: monitoring hadn't alerted on the disk errors that\npreceded the failure by days — the fix is SMART/checksum alerting.
\nAdding a NOT NULL column to a billion-row table. Run naively, the migration\nrewrites every row, holds an exclusive lock, and takes the app down for an hour.\nThe DBA does it online: add the column nullable (instant in modern Postgres),\nbackfill in throttled batches, then validate — zero downtime.
\n","wordCount":227},{"heading":"Related Occupations","id":"related-occupations","markdown":"The database administrator shares the irreplaceable-state mindset of the site\nreliability engineer but specializes in the data tier — a specialization SREs\noften grow into as \"database reliability engineering.\" Backend engineers write the\nqueries and schemas the DBA reviews and tunes. Data engineers take the same data\ndownstream into analytical pipelines, reasoning in throughput rather than\ntransactional correctness. Security engineers share access control, encryption, and\naudit; systems administrators manage the hosts and storage.","html":"The database administrator shares the irreplaceable-state mindset of the site\nreliability engineer but specializes in the data tier — a specialization SREs\noften grow into as "database reliability engineering." Backend engineers write the\nqueries and schemas the DBA reviews and tunes. Data engineers take the same data\ndownstream into analytical pipelines, reasoning in throughput rather than\ntransactional correctness. Security engineers share access control, encryption, and\naudit; systems administrators manage the hosts and storage.
\n","wordCount":73},{"heading":"References","id":"references","markdown":"- *Database Internals* — Alex Petrov\n- *Designing Data-Intensive Applications* — Martin Kleppmann\n- *SQL Performance Explained* — Markus Winand\n- *Database System Concepts* — Silberschatz, Korth, Sudarshan\n- *The Art of PostgreSQL* — Dimitri Fontaine","html":"