How to get hired as a database administrator in 2026-27

The title is shrinking. The work is not.

If you search job boards for Database Administrator and conclude the profession is ending, you have searched one string. The title is genuinely in decline at product and technology companies, where the same work is posted as Database Reliability Engineer, Database Engineer, Cloud Database Engineer, Platform Engineer with a data infrastructure focus, or Site Reliability Engineer on a storage or database team. Meanwhile the title is alive and ordinary in the parts of the economy that run large, old, regulated, expensive database estates and will keep running them for years.

That split matters because the two groups hire differently. An enterprise or public-sector DBA posting is read by an agency recruiter or an applicant tracking system doing near-literal keyword matching, so the resume has to say Always On Availability Groups rather than high availability, and Oracle Data Guard rather than replication. A platform or reliability posting is read by an engineer who will skim your product nouns and then ask what you do when the primary stops accepting writes at 3 a.m. You can target both, but not with one document: keep two versions and send the right one.

Inside the enterprise group, the seat you are most likely to get first is the second DBA. One person has run the estate for years, the organisation has finally admitted that a single point of failure wearing shoes is a risk, and they are hiring someone to share the pager and take the work nobody has had time for. That job is usually described in the posting as supporting the senior DBA, and it is the best possible entry: a real estate, a person to learn from, and an obvious first project, because the backlog in those shops is always some combination of untested restores, out-of-support versions and monitoring nobody tuned.

The other structural fact about this role is the channel. A large share of DBA hiring in the United States goes through staffing agencies as contract or contract-to-hire, particularly in healthcare, government and finance. That is not a lesser route. Contract-to-hire is often the fastest way to get your hands on an estate you could never have reached as an external applicant, and six months of it converts into a permanent offer or into a reference and a far better resume. The trade is benefits, notice and how you get treated, so price the rate accordingly and ask directly whether conversions have actually happened for other people on that account.

Public sector deserves its own warning, because people apply to it the way they apply to everything else and then hear nothing. Federal postings run through a self-assessment questionnaire that decides whether a human ever sees your resume, and the federal resume convention is long form with start and end dates, hours per week and explicit duty statements rather than a tight two-pager. State and county postings often require that every listed requirement be visibly addressed somewhere in the application, and a reviewer who cannot find it scores it as absent. The process is slow, the posting closes on a fixed date whether or not anyone has been interviewed, and the pay band is published. If you want that stability, write the application the way that system expects.

• Sectors still posting the literal title: hospital systems and payers, government at every level, banks, credit unions and insurers, universities, utilities and telecoms, defense contractors, logistics, manufacturing and retail chains, gaming, and MSPs and consultancies.
• Titles carrying the same work elsewhere: Database Reliability Engineer, Database Engineer, Cloud Database Engineer, Data Platform Engineer, Infrastructure Engineer (Databases), SRE (Storage or Databases), and in smaller shops Systems Administrator where the database is half the job.
• Engine-specific strings worth searching separately: Oracle DBA, SQL Server DBA, PostgreSQL DBA, MySQL DBA, MongoDB DBA, Db2 DBA, plus SAP Basis and Epic Clarity roles, which are database work under another name.
• Channels that actually produce interviews: staffing agencies with a named enterprise account, MSP career pages, USAJOBS and state and county portals, user group communities (PostgreSQL meetups and PGConf, the PASS Data Community, regional Oracle user groups), and direct applications to employers whose estate you already know.
• Worth a saved search of its own: postings that say supporting the senior DBA, second DBA, or junior DBA. That is where entry-level hiring in this field still happens.

What managed cloud databases took away, and what they handed you instead

Amazon RDS and Aurora, Azure SQL Database and Managed Instance, Google Cloud SQL and AlloyDB, and Oracle Autonomous Database removed a specific list of tasks: installing the engine, scheduling and retaining backups, standing up a replica, applying a patch during a window, and configuring the plumbing of a failover. Those tasks were the apprenticeship. They were how people learned an engine at 2 a.m. with the manual open. Their disappearance is the real reason entry-level DBA postings are scarce, and it is why the honest advice to a career changer is to get adjacent first and claim the database work from inside a sysadmin, support or platform job.

What managed services did not remove is anything that requires a decision. A managed service will take a backup; it will not tell you that your one-hour recovery time objective is unreachable because restoring four terabytes and replaying the logs takes longer than that. It will replicate; it will not decide whether you accept data loss on failover or pay the write latency of synchronous commit. It will patch; it will not negotiate the maintenance window with the clinical application owner, notice that the forced major version upgrade lands in your financial close, or know that one extension you depend on is unavailable on the target version.

Several things got harder. Cost became a first-class database concern, because provisioned IOPS, oversized instances, idle replicas, cross-region traffic and snapshot storage are line items somebody will ask you to explain. Staying on an old major version is now a billed choice as well as a risk, since the cloud providers charge extra to keep running a version past the end of its standard support, which turns a deferred upgrade into a number the finance team can see. Diagnosis changed shape, because you no longer get the host: you get metrics, Performance Insights or Query Store, and parameter groups you can only partially override. And in a shared cloud account, proving a restore means standing up a separate instance and paying for it, which is exactly the test people skip and exactly the one that ends careers.

None of this makes on-premises skills obsolete. A large fraction of the estates that still employ DBAs are not in a hyperscaler at all, or are half migrated and will stay that way for years. Knowing storage, filesystems, fsync behaviour, memory and the actual mechanics of write-ahead logging is what lets you reason about a managed service when the console stops explaining itself. Candidates who learned only the console are visibly stuck the moment a question goes one level below it.

• Gone or heavily automated: engine install, backup scheduling, replica provisioning, failover plumbing, minor patching, routine index rebuild jobs.
• Still yours, and now most of the job: recovery design and proof, HA and DR topology and the data loss you accept, major version upgrades and migrations, schema change safety, access control and audit, capacity, and cost.
• New in the managed world: parameter groups instead of config files, IAM and network reachability as database problems, maintenance windows negotiated against a vendor-imposed deadline, extension and feature availability decided by the provider, and a bill you will be asked to defend line by line.
• The skill that transfers both ways: being able to say what the engine is doing underneath, in terms of write-ahead log, checkpoints, buffer cache, locks and plans, rather than in terms of which button you clicked.

The depth that gets tested, engine by engine

Postings list six engines. Interviews test one, usually the one that estate runs, at a depth that cannot be faked. The right strategy is one engine you can defend to the floor, working literacy in a second, and honesty about the rest. Nobody has been rejected for saying they have run Postgres and Oracle but only read about Db2. People are rejected constantly for listing an engine and failing the first real question about it.

The cross-engine fundamentals are what separate a DBA from a developer who writes good SQL, and they get tested whichever product is on the box: how a write becomes durable, what a checkpoint costs, how isolation levels change what a reader sees, why a long-running transaction is dangerous even when it is idle, what an index costs on write and in maintenance, how an optimizer uses statistics and why a plan can flip overnight, and what a restore physically consists of. If you can explain multiversion concurrency control and then explain why it means your oldest open transaction can bloat a table, you are speaking the language.

PostgreSQL is where most new work and most migrations off commercial engines are going, so it is the highest-return engine to learn if you are choosing one. The questions that come up are vacuum and bloat, transaction ID wraparound, why connections are not free and where PgBouncer fits, reading EXPLAIN (ANALYZE, BUFFERS) rather than quoting a cost number, pg_stat_statements as the first stop in a slow-system question, logical versus physical replication and what logical replication does not carry (sequences, DDL, large objects), partitioning, and upgrade paths including pg_upgrade and logical-replication cutovers. Know the backup tooling by name as well: pgBackRest or Barman for physical backup and point-in-time recovery, and why pg_dump is a logical export rather than a recovery strategy for a large estate. Extension literacy counts too, because half the estate is pg_stat_statements, pg_repack, PostGIS and pgvector, and a managed service deciding which of them you are allowed.

SQL Server estates test wait statistics, Query Store and forced plans, parameter sniffing and what you do about it, tempdb configuration and contention, Always On Availability Groups versus failover cluster instances and the difference in what each protects, backup chains with full, differential and log backups, and licensing by core, which is a genuine DBA responsibility because consolidation decisions turn into six-figure invoices. Oracle estates test AWR and ASH reading, RMAN backup and recovery including incomplete recovery, Data Guard roles and protection modes, RAC concepts, optimizer statistics and SQL plan management, and the commercial side, which is where candidates get caught: AWR and ASH sit in the Diagnostics Pack, so running them on an instance that is not licensed for it is an audit finding, and virtualization choices and option usage create licence exposure the DBA is expected to know about. MySQL, MariaDB and Aurora test InnoDB internals, the binary log and GTIDs, replication lag and how to measure it honestly, and online schema change tooling such as gh-ost or pt-online-schema-change, because although recent MySQL versions make some ALTERs instant, the ones that rebuild a large hot table are still the classic outage.

Then there is the half of the job that is not the engine. Linux, because almost every Postgres, MySQL and Oracle estate sits on it and you will be asked to read iostat output or say what the page cache is doing. Scripting, because manual administration does not scale and nearly every modern posting expects some automation. Infrastructure as code and migration tooling, because schema changes now arrive through a pipeline rather than a change ticket. Monitoring, named specifically: Prometheus exporters, Datadog Database Monitoring, SolarWinds, Redgate, Quest Foglight, or the native stack. Name what you ran, not the category.

• Cross-engine fundamentals: write-ahead logging and durability, checkpoints, isolation levels and anomalies, locking versus blocking versus deadlock, index structures and their write cost, statistics and plan stability, and what a restore physically does.
• PostgreSQL: MVCC and vacuum, bloat and wraparound, pg_stat_statements, EXPLAIN (ANALYZE, BUFFERS), connection pooling, logical and physical replication, partitioning, pg_upgrade, pgBackRest or Barman, extension availability on managed services.
• SQL Server: wait statistics, Query Store and plan forcing, parameter sniffing, tempdb, Always On Availability Groups versus FCI, backup chain and log shipping, core-based licensing and its consolidation consequences.
• Oracle: AWR and ASH and the Diagnostics Pack licence they require, RMAN including point-in-time and tablespace recovery, Data Guard protection modes, RAC fundamentals, optimizer statistics and SQL plan management, option and virtualization licence exposure.
• MySQL, MariaDB and Aurora: InnoDB buffer pool and redo, binlog and GTID replication, replication lag measurement, online schema change tooling, and Aurora storage behaviour where it differs from stock MySQL.
• NoSQL and adjacent, where the posting asks: MongoDB replica sets, elections, write and read concern; Redis persistence and eviction; and enough of a cloud warehouse to say why it is not an operational database.
• Operations: Linux and storage behaviour, shell or Python or PowerShell scripting, Terraform or Ansible, Flyway, Liquibase or Sqitch for schema migrations, CI that runs migrations, and a named monitoring stack with alerts you actually tuned.

How the hiring process really runs

There is rarely a take-home. That surprises people arriving from software hiring, but it follows from the job: you cannot hand a candidate a production incident, and a toy schema exercise tests the wrong thing. What replaces it is scenario interviewing, usually conversational, sometimes with a whiteboard or a shared document, and what the interviewer is reading is whether you reason in a defined order under pressure or start guessing.

Who screens you changes the first conversation completely. In enterprise and public sector it is frequently an agency recruiter working a keyword list, which is why near-literal product names in the resume matter more here than in almost any other role. Next is a hiring manager who may be an infrastructure director rather than a database specialist, and whose real questions are about risk: will this person tell me early when something is wrong, will they refuse a change that is unsafe, and will they carry a pager. The deep technical round comes from the senior DBA or a lead engineer, and in regulated shops there is a separate conversation with security or compliance about access, separation of duties, audit trails and who can see production data.

Two sector-specific gates are worth planning around. Healthcare: most hospital database jobs sit around Epic or Oracle Health, and the vocabulary matters. Epic's transactional system runs on InterSystems technology and is administered through Epic's own tooling, while the reporting layers, Clarity and Caboodle, are SQL Server or Oracle, which is where the conventional DBA jobs are. Epic certification is granted through employer sponsorship and cannot be bought, so the sequence is get hired into a system first, get certified second. Government and defense: a clearance must be sponsored, the process takes months, and a posting that says clearance required almost always means an active one, so filter rather than hope. Both sectors run background checks and sometimes drug screening, which appears at offer stage and adds weeks.

On-call is part of the compensation conversation and you should raise it, rather than discovering it in week two. Ask how many people are in the rotation, how often the pager actually fires at night, what the maintenance windows are and how often they are used, who authorizes an emergency change, and whether there is any time back after a bad night. A two-person rotation on a 24-hour clinical system is a different job from a six-person rotation on an internal reporting estate at the same salary, and asking reads as professional rather than reluctant.

The references stage is more real here than in most roles, because this is a trust hire. Managers call people and ask whether you were the person who caused the outage or the person who recovered from it, and whether you escalate early. Keep two managers and one application-side partner who can speak to a specific incident you handled, and tell them which role you are up for so they tell the right story.

• Usual stages: screen, hiring manager, deep technical scenario round, sometimes an application or security panel, references, background check, and in regulated sectors a drug screen.
• Typical elapsed time: days to two weeks through a staffing agency, two to five weeks direct in the private sector, months in government.
• What the manager is actually testing: whether you escalate early, refuse unsafe changes, and can be trusted with production access unsupervised.
• Ask before you accept: rotation size and night pager frequency, change control and who approves emergency changes, maintenance windows, how many people hold production write access, the oldest version still running and whether its upgrade is funded, and when the last full restore test happened.
• If the answer to the last restore test is that nobody knows, that is not a reason to decline. It is your first project, and saying so in the interview is often what wins it.

The four scenarios that decide the technical round

Almost every database interview reduces to four scenarios. Prepare them as methods with named tools on your engine, not as trivia, because the interviewer is grading the order you do things in and what you refuse to do.

One: the database is slow. The wrong answer starts guessing at indexes. The right answer defines slow first (which operation, since when, everyone or one user, against what baseline), then goes to evidence: what the system is waiting on, then the top statements by total time rather than by worst single execution, then one plan read properly, then the smallest safe intervention. Name where you look on your engine, because that is the difference between having done this and having read about it: pg_stat_activity and pg_stat_statements on Postgres, sys.dm_os_wait_stats and Query Store on SQL Server, ASH and AWR on Oracle. Say out loud what you will not do during business hours: no index build without knowing the locking behaviour on that engine and version, no statistics update on a critical table at peak, no restart as a first move because it destroys both the evidence and the cache. Finish with how you would prevent a recurrence, because that is where senior candidates separate themselves.

Two: recover it. Someone ran a DELETE with no WHERE clause at 14:10 and committed it. Walk the mechanics: which backup is the base, which log or archive chain gets replayed, how you restore to 14:09 rather than to the last full backup, whether you restore in place or to a side instance and copy the rows back (almost always the second, because it is reversible and leaves production running), what you tell the business about the window of lost work, and roughly how long the restore physically takes at your data volume. Then the question behind the question: when did you last do this for real, and how do you know the backups are good. The only credible answer is a scheduled restore test with evidence, and the candidate who says that a backup you have never restored is not a backup, and then describes their own test cadence, has effectively passed.

Three: it failed over. Be precise about synchronous versus asynchronous replication and the data loss each implies, what quorum or a witness is for, what split brain is and what fencing or automatic demotion prevents it, what the application sees (connection strings, listener or endpoint, DNS and its cache, connection pool behaviour, retry logic), and what failing back involves including reseeding a stale replica. The judgment part is knowing that automatic failover is a decision someone made in advance about acceptable data loss, and being able to say which choice you would make for a payments system and which for a reporting system, and why they differ.

Four: blocking, deadlocks, and whether to add that index. These test whether you know the difference between a session waiting and a system that has detected a cycle and killed somebody. Expect to explain isolation levels and what each prevents, why a transaction left open by an application that went to lunch can stall a system, where you find the blocking chain on your engine, and the fix hierarchy: shorten the transaction, fix the access path, adjust isolation only deliberately, and treat killing sessions as triage rather than a fix. On indexes, the strong answer is a cost answer: every index is paid for on every write, in storage and in maintenance and sometimes in plan stability, so name what it fixes, what it slows, how you will create it without locking (CREATE INDEX CONCURRENTLY, ONLINE = ON, or the equivalent on your engine), and when you will check whether it is being used.

Expect one more round in enterprises that is not technical at all: change control. How a schema change gets from a developer to production, who approves it, what the rollback is, what you do when a change goes wrong at 22:00 on a Friday, and when you have told someone no. Have a real story for the no. It is often the most informative answer you give.

• Slow system: define slow, read the waits, rank statements by total time, read one plan, smallest safe change, then prevention. Name the views and tools on your engine, and name what you refuse to do at peak.
• Recovery: base backup plus log chain, restore to a point in time, side instance rather than in place, state the data loss window, and know the real duration at your data size.
• Failover: synchronous versus asynchronous and the data loss each accepts, quorum and fencing, what the application and its connection pool experience, and how failback and reseeding work.
• Concurrency: isolation levels, blocking chains, deadlock graphs, the long idle transaction, and a fix hierarchy that does not start with killing sessions.
• Change control: approval path, rollback plan, emergency process, and one story about refusing an unsafe change.

The resume that gets past the screen, and the evidence to build if you have none

Two pages is normal and nobody will penalise it. Federal applications are different again and run long by convention, with explicit dates, hours per week and duty statements. In both cases the first job of the document is literal matching, because an agency recruiter or an applicant tracking system is comparing strings. Write Always On Availability Groups, Oracle Data Guard, RMAN, pg_stat_statements, Azure SQL Managed Instance, Amazon RDS for PostgreSQL. Write the versions, because estates are version-specific and a manager running SQL Server 2019 wants to see it. Do not abstract your experience into high availability and performance tuning, which match nothing.

The second job is scale. A DBA resume without magnitudes is unreadable, because administering three small databases and administering four hundred across a hospital system are different professions described in identical words. Put the estate in the first two lines of each role: how many instances and databases, total size in terabytes, the busiest system and its transaction or batch volume, the uptime target, the criticality (clinical, payments, regulated), and the size of the rotation you were in.

The third job is outcomes with numbers attached. Recovery objectives you met and the restore test that proved it. An upgrade or migration with the version pair and the downtime window you achieved against the one you were given. A tuning project with before and after latency on a named report or transaction. A cost reduction with the lever that produced it: right-sizing, storage tier, removing an idle replica, consolidating instances to cut core licensing. An outage you helped recover, with how long detection took and how long recovery took. If exact figures are confidential, give the order of magnitude, because orders of magnitude are credible and adjectives are not.

If you do not have an estate yet, build the evidence rather than claiming it. A lab is cheap and specific: two Postgres or SQL Server instances in containers or small VMs, streaming replication or an availability group between them, a load generator writing continuously, and then the three exercises that matter. Kill the primary and time the failover. Take a base backup, archive the logs, drop a table at a known time, and restore to the second before it, writing down how long it took at that data size. Then script the whole rebuild so you can do it again from nothing. What goes on the resume is not I built a home lab, it is a one-line result with a number: restored a 200 GB Postgres instance to a chosen point in time in 38 minutes, verified by row count, from a script in this repository. The same applies at work if nobody has tested a restore: run one into a scratch instance, write the result down, and you now own a line nobody else in the building can write.

What is routinely ignored: proficiency tables with star ratings, the phrase responsible for, bullets that restate the job description (monitored database health, ensured data integrity, performed daily backups), and a summary paragraph of adjectives. Also ignored, by engineers at least, is a long list of engines with no depth anywhere, because it reads as exposure rather than experience. If you are aiming at platform and reliability postings, add the engineering evidence those teams look for: a public repository, Terraform or Ansible you wrote, a migration pipeline, a runbook, a dashboard you built. One public artefact beats three more bullets.

• Open each role with the estate: instances, databases, terabytes, peak volume, uptime target, criticality, rotation size.
• A recovery line, every time: RPO and RTO targets, whether you met them, and the date and method of the last proven restore test.
• Projects with a version pair and a window, for example: upgraded 112 SQL Server instances from 2016 to 2022 over nine months, no unplanned downtime, worst case 20 minutes per instance. Use your own real numbers in that shape.
• Tuning with before and after, for example: reduced the nightly billing batch from 6 hours 40 minutes to 55 minutes by replacing a row-by-row cursor and adding one covering index.
• Cost and licence with the lever: consolidated idle instances, moved a workload off provisioned IOPS, reduced Oracle licensable cores by isolating the estate onto pinned hosts.
• Automation, named: Ansible playbooks for patching, a Flyway pipeline that gates every schema change through CI, a job that restores last night's backup into a scratch instance and checksums it weekly.
• Cut entirely: star-rating skill tables, responsible for, duty-statement bullets, and any engine you cannot defend for ten minutes.

Repositioning DBA experience for platform, reliability and data infrastructure roles

If you want the other half of the market, the one that pays more and does not use the title, the translation is mostly vocabulary plus two genuine gaps. The vocabulary first. Backups and restores become recovery objectives and tested disaster recovery. Maintenance scripts become automation and change safety. Query tuning becomes latency objectives and capacity. Patching becomes lifecycle management. On-call becomes incident response, and lead with that one, because reliability teams are short of people who have actually been woken up and stayed calm. A DBA with ten years of production incidents has the single most valuable thing an SRE team hires for and usually undersells it.

The two real gaps are code and infrastructure as code. Platform interviews will ask you to write something, usually small: parse a log, call an API, script a check. They will ask how you would provision the thing you are describing, and they expect Terraform or an equivalent rather than a console. Close these deliberately rather than claiming them. A public repository with your own tooling in it, however modest, changes the conversation: a backup verification job, an exporter, a migration gate, a script that diffs schema between environments.

Do not throw away the specialism on the way. The failure mode is a DBA who rewrites their resume into generic cloud engineering, loses the thing that made them distinctive, and competes against a thousand people with the same certification. The strong version is specialist depth plus engineering practice: the person who can explain why the plan flipped after the statistics refresh and show the pipeline that catches it next time. That combination is scarce, and it is what Database Reliability Engineer postings are trying to describe.

One honest note on direction. Database architect, data architect and data platform lead are natural progressions and sit higher in the published pay bands. Moving toward data engineering is also common, but it is a different job: pipelines, modelling and analytics consumers rather than uptime and recovery. Pick deliberately, because the resume that gets you an architect interview and the one that gets you a data engineering interview emphasise opposite halves of the same career.

• Translate, do not inflate: tested DR, recovery objectives, latency and capacity, lifecycle management, incident response, change safety.
• Lead with incident experience. Reliability teams hire for calm under production pressure and you have more of it than most applicants.
• Close the two gaps for real: a scripting language you can be tested in, and infrastructure as code you have actually applied.
• Keep the specialism visible. Depth in one engine plus engineering practice beats generic cloud fluency.
• Know which direction you are choosing: architect and platform lead keep the uptime and design brief; data engineering trades it for pipelines and analytics consumers.

What a screen is looking for

These are the terms that a resume screen, human or automated, is matching against for this role. Use the ones that are true of you, in the words the posting uses.

• Database administration
• Database Administrator
• DBA
• PostgreSQL
• PostgreSQL administration
• Oracle Database
• Oracle 19c
• Oracle 23ai
• Microsoft SQL Server
• SQL Server 2019
• SQL Server 2022
• MySQL
• MariaDB
• MongoDB
• Db2
• Amazon RDS
• Amazon Aurora
• Azure SQL Database
• Azure SQL Managed Instance
• Google Cloud SQL
• AlloyDB
• Oracle Autonomous Database
• High availability
• Disaster recovery
• RPO
• RTO
• Point-in-time recovery
• Backup and recovery
• RMAN
• pgBackRest
• Oracle Data Guard
• Oracle RAC
• Always On Availability Groups
• Failover clustering
• Log shipping
• Replication
• Logical replication
• Streaming replication
• Performance tuning
• Query tuning
• Execution plans
• Wait statistics
• Query Store
• AWR
• ASH
• pg_stat_statements
• Index design
• Partitioning
• VACUUM
• MVCC
• Deadlock resolution
• Blocking and locking
• Isolation levels
• Capacity planning
• Database security
• Row-level security
• Data masking
• Auditing
• SOX
• HIPAA
• PCI DSS
• Change management
• Schema migrations
• Flyway
• Liquibase
• gh-ost
• pt-online-schema-change
• Terraform
• Ansible
• Python scripting
• PowerShell
• Bash
• Linux administration
• Prometheus
• Datadog Database Monitoring
• Database reliability engineering
• Site reliability engineering
• On-call
• Cloud cost optimization
• Oracle licensing
• SQL Server licensing
• pgvector
• Vector indexes
• PgBouncer
• Database upgrades
• Migration to PostgreSQL
• Epic Clarity
• Epic Caboodle

Mistakes that cost people this job

Questions people ask