Nobody notices the database until it's slow, and then everyone notices you. A database administrator keeps the data safe, fast and recoverable, which sounds quiet until a restore fails at the worst possible moment. Here's how the job changes as you move up, and what people actually check before they hand you the keys.
The real job is being the person who says no. A developer wants to add an index in production at noon. A product team wants a column dropped before anyone has checked what reads it. You're the one who asks what happens if it goes wrong, and you'll be unpopular for a day.
Then there's the pager. Most teams rotate on-call, and a replication lag alert at night doesn't care that you have a dentist appointment in the morning. The people who last in this job make peace with that early. They also get obsessive about backups, because a backup you've never restored is a guess, not a backup. If you like being the calm one in a room full of panicked engineers, this is a good fit. If you want to ship features and move on, you'll find it frustrating.
You run the checklists. You watch backup jobs, apply patches in maintenance windows, reset permissions and write the tickets when something looks off. People judge you on whether you follow the runbook exactly and whether you escalate early instead of guessing. Most people get here from help desk, systems administration or a reporting role where they wrote a lot of SQL.
You own a set of production databases, often SQL Server, PostgreSQL, Oracle or MySQL. You tune slow queries, read execution plans, plan capacity, set up replication and run restore tests. You sit in change review meetings and push back on risky schema changes. You're judged on uptime, on how fast you find the real cause of a slowdown, and on whether developers trust your answers.
You design the setup instead of just running it: high availability, disaster recovery, failover you've actually tested. You automate the boring work with PowerShell, Python or Ansible, and you lead the incident call when production goes down. You mentor the juniors and write the standards everyone else follows. People judge you on the outages that didn't happen.
The ladder forks here. One branch is management: you run the team, own the budget and the on-call rota, and sit with vendors about licensing. The other is the expert track, where you become a data platform or database reliability engineer, working on cloud migrations to services like Amazon RDS, Azure SQL or Aurora and building tooling so databases get created and patched through code. Some people go sideways into data architecture instead.
Expect a live question on each of these; a list on your resume won't carry you past someone who's done the job.
A lot of DBAs stall at the middle rung. They're good at keeping things running, so nobody lets them build anything new. The way out is automation. Script the thing you do by hand every week, whether that's user provisioning, index maintenance or restore tests, and put it in source control where others can see it.
The second move is learning the cloud version of whatever you run. Moving a database to a managed service changes your job from patching servers to handling cost, performance and failover on someone else's hardware. Teams want people who've done that migration once and know where it bites. A vendor certificate from Microsoft, Oracle or AWS can help you get the interview. It won't answer the question about why a query plan flipped overnight. Only time with real systems does that.
6% of openings are fully remote.
$107,900 – $192,325
Typical range in the 26 of the newest 60 postings that list pay.
No, though some employers list one. Plenty of DBAs came up through help desk, systems administration or data reporting, where they got good at SQL and volunteered for database work. What matters more is proof you can restore a database, tune a slow query and explain what you did. A home lab with a few databases you've broken and fixed is a good start.
The job is changing, not going away. Managed services take patching and hardware off your plate, but someone still has to design the schema, tune queries, control access, plan for failure and keep the cloud bill sane. The DBAs who struggle are the ones who only know how to install and patch. Learn automation and at least one cloud platform, and you'll be fine.
Look at the postings near you and pick the one that shows up most. For a lot of people that's SQL Server in corporate IT or PostgreSQL at software companies. Oracle still runs a great deal of finance, government and older enterprise systems. The core ideas carry over, so going deep on one beats knowing a little about four.
It depends heavily on the employer. A team supporting customer-facing systems usually runs a weekly rotation, and some weeks you'll get paged at night. Internal systems at a smaller company might page you rarely. Ask in the interview how often the pager actually goes off and what the last few incidents were, because the honest answer tells you a lot about the team.