The page that wakes a database administrator at 03:40 rarely announces a crash. It says a replica has fallen four hours behind and the morning reporting job is already reading from it. By the time the laptop is open, three people have asked the same question in three different channels, and none of them want the technical explanation. They want to know whether the numbers in tomorrow's board pack will be right.
A Backup Nobody Restored Is a Guess
That 03:40 page is the honest center of this work. A database administrator is the person an organization holds responsible for whether its data is present, correct, and recoverable. Present means the application can read and write it during the hours people need it. Correct means the rows say what actually happened, including the ones written at two in the morning by a retry loop nobody documented. Recoverable means that when a disk fails, a deploy goes wrong, or somebody with the delete permission has a bad afternoon, there is a copy that comes back and a procedure that has been run before, by a human, with a timer running.
Most of the visible work looks small. A migration reviewed for twenty minutes. A permission granted to one role instead of one person. An index added and two others dropped. A parameter changed and written down. The invisible work is where the job lives, because a database that behaves well produces no evidence of the decisions that kept it that way. There is no dashboard panel called "outage that did not happen." This is why junior administrators often mistake activity for progress and why experienced ones keep a change log that reads like a diary of boring afternoons.
The role also carries a permanent translation duty. A product manager asks for a feature. A developer asks for a schema change. A finance team asks why a report ran six hours late. An auditor asks who could read the salary table in March. All four questions land on the same desk, and the answer has to be given in the language of the person asking without losing the constraint underneath it. A DBA who answers only in technical terms gets ignored until something breaks. A DBA who answers only in business terms gets overruled into an unwise change. The job sits in the middle, holding both.
What separates an administrator from a developer who happens to know SQL is the direction of attention. A developer asks whether the query works. An administrator asks what happens to the rest of the system when ten thousand copies of that query arrive at once, and what happens tomorrow when the table has tripled. Both questions are technical. Only the second one is about consequences at a distance, which is the skill this role is actually paid for.
The Job Is Deciding What Must Never Break
Every database decision reduces to three questions that are not technical at all. Which data cannot be lost under any circumstances? How long can the business survive without reading or writing it? Who is allowed to see which rows? A new administrator can spend weeks learning storage engines before noticing that nobody in the building has answered those three questions in writing.
The first question sets the backup policy. A table of marketing preferences and a table of payment settlements do not deserve the same retention, the same replication, or the same restore drill. When everything is treated as critical, nothing gets the attention it needs, and the backup job grows until it can no longer finish inside its window. Sorting data into tiers is unglamorous work that prevents a specific failure: the restore that takes eleven hours because nobody separated the tables that mattered from the ones that did not.
The second question sets the architecture. A team that can tolerate four hours of downtime can run a simpler, cheaper system than a team that cannot tolerate four minutes. Cloud pricing pages encourage the second answer because it sells more infrastructure. The honest answer usually sits somewhere in between, and it changes as the business changes, which means the conversation has to happen again every year rather than once.
The third question sets the access model. Roles instead of individuals, grants that expire, and a written record of why each grant exists. This is the part of the role that generates the most friction, because a permission request is a person asking to do their job and an administrator asking them to wait until Friday. Handled badly, it produces a shared admin password kept in a chat message. Handled well, it produces a short list that an auditor can read in ten minutes.
None of this shows up in a tutorial. Tutorials teach syntax because syntax is teachable. The judgment about which table deserves synchronous replication comes from having watched a restore fail, or from working next to somebody who has.
The Ground a DBA Stands On
Four catalog areas feed this role, and each one contributes something the others cannot.
Query language, the daily grammar
Databases & Backend is the home area, and the catalog holds 31 live resources in it, with 27 free and 4 paid. This is where the language of the job lives: joins, aggregates, window functions, transactions, isolation levels, and the query plans that explain why one statement returns in forty milliseconds while its near-twin takes nine seconds. A beginner who cannot read a plan is guessing at every performance conversation.
Start with Select Star SQL (FREE), a guided workbook that teaches joins and grouping through real questions rather than syntax drills. Pair it with PostgreSQL Official Tutorial (FREE), which walks the same material inside the engine most teams actually run. When a concept refuses to land, PostgreSQL Exercises (FREE) gives you a graded set of problems and DB Fiddle (FREE) lets you paste a query and see the result without installing anything. Those four cover the first month without a single payment.
The server under the schema
DevOps & Cloud supplies the machine. The catalog lists 30 live resources in DevOps & Cloud, of which 26 are free and 4 are paid. A database is a process on a host with a filesystem, a memory budget, a network path, and a log file that fills up when you are not looking. Administrators who never learned the host end up escalating every disk alert to somebody else, which is a strange position for a person responsible for storage.
Linux Foundation: Introduction to Linux (LFS101) (FREE) covers permissions, processes, and the command line without assuming a computer science background. DigitalOcean Community Tutorials (FREE) has the practical installments on installing, securing, and backing up a server that most courses skip. Docker Get Started (FREE) teaches enough containers to run a database locally exactly as it runs in staging, and KodeKloud DevOps Free Labs (FREE) gives you a browser-based terminal when your own laptop cannot host another service.
Pipelines that move the rows
Data Engineering explains where the data came from and where it goes next. Data Engineering carries 30 live resources, including 27 free and 3 paid. A production database is rarely the whole story. Rows arrive from an application, leave for a warehouse, get transformed by a scheduled job, and come back as a report that an executive trusts. An administrator who does not understand that path cannot explain why the warehouse numbers disagree with the application numbers at month end.
dbt Fundamentals (dbt Learn) (FREE) is the clearest introduction to transforming data in version-controlled steps. Apache Airflow Tutorial (FREE) covers the scheduler that runs most of these jobs, and Great Expectations Docs (FREE) shows how to assert that data is shaped the way downstream consumers expect. Data Engineering Wiki (FREE) is the reference to keep open when a term appears in a meeting and nobody defines it.
Code review as a database skill
Software Engineering matters because schema changes arrive as code. Software Engineering holds 36 live resources, with 30 free and 6 paid. A migration file is a program with side effects on data that cannot be regenerated. Reading it the way a reviewer reads application code is a skill, and it is the one most self-taught administrators lack.
Git and GitHub for Beginners (Mohin Sheikh) (FREE) gets you comfortable with branches and pull requests, which is where migration review happens. Software Engineering at Google (free ebook) (FREE) is unusually good on the culture of review and the cost of long-lived change. Big-O Cheat Sheet (FREE) is a one-page reminder of why an index that helped a thousand rows hurts a million.
Read together, the four areas describe one working whole. The query language tells you what the database should do. The server tells you what it costs. The pipeline tells you who depends on the answer. Code review tells you how change reaches production without a surprise. A learner who trains only the first will write beautiful queries that take down a replica.
Learning It in the Order Production Teaches It
There is no single correct sequence, but there is a sequence that produces a person who can be left alone with a system. It runs from writing a query to defending a restore, and each stage has a test you can apply to yourself rather than a certificate to collect.
Stage one: make a query answer a real question. Not a syntax exercise. Take a public dataset, a spreadsheet from your own life, or a sample database and ask something you actually want to know. Select Star SQL (FREE) structures the first pass, PostgreSQL Tutorial (FREE) fills the gaps in order, and Exercism SQLite Track (FREE) gives you feedback on exercises you submit. Done means you can take a question in plain English and produce a query that answers it without consulting a search engine for syntax.
Stage two: learn what the engine does with the query. This is where the role separates from data analysis. CMU 15-445 Intro to Database Systems (FREE) is a full university course on storage, indexing, and query execution, and it is the single best free investment of a hundred hours in this roadmap. Keep PostgreSQL Documentation (FREE) open beside it, because the official manual explains the specific behavior of the engine you will be paid to run. DuckDB Documentation (FREE) is a useful second engine to compare against, since its design choices make the trade-offs visible. Done means you can read an execution plan and say which step is expensive and why.
Stage three: operate the machine, not just the query. Linux Foundation: Introduction to Linux (LFS101) (FREE) covers the shell, permissions, and process management an administrator uses hourly. Play with Docker (FREE) gives you a disposable environment to break, and Docker Curriculum (FREE) explains what you are breaking. Add Killercoda (FREE) for scenario-based practice that includes a real terminal in a browser tab. Done means you can install a database server, create a role, and connect to it from a client on another host without following a screenshot.
Stage four: make change reversible. GitHub Actions Documentation (FREE) teaches the automation layer where migrations actually run. Ansible Resources (FREE) covers configuration that can be replayed instead of remembered. Google Site Reliability Engineering Book (FREE) is the best free text on change management and error budgets, and its chapter on release engineering explains why a small, frequent change is safer than a large, rare one. Done means you can describe, in writing, how a schema change moves from a pull request to production and how it is undone.
Stage five: move data without breaking it. dbt Fundamentals (dbt Learn) (FREE) is the fastest route into the vocabulary of models and tests. Great Expectations Docs (FREE) covers the validation layer that catches a broken upstream feed before a report does. Snowflake Quickstarts (FREE) walks through a warehouse end to end, and Apache Airflow Tutorial (FREE) shows the scheduling that ties it together. Done means you can trace one number from an application table to a dashboard and name every transformation in between.
Stage six: prove recovery under pressure. Recovery is the part everyone claims to have and few have tested. Work through the backup and point-in-time recovery chapters of PostgreSQL Documentation (FREE) until the sequence is familiar, then run it on Killercoda (FREE) with a timer visible. Kubernetes Basics Tutorial (FREE) is worth a weekend for the vocabulary alone, because stateful workloads increasingly run inside orchestration and the questions change when they do. Done means you have restored a database from a backup, on a machine that was not the original, and written down how long it took.
The order matters because each stage assumes the one before it. An administrator who learns orchestration before query plans will automate a system they cannot diagnose. An administrator who learns backup tooling before understanding write-ahead logging will produce backups that restore to an inconsistent state and will not find out until the worst possible day.
There is also a pace question worth stating plainly. Stages one and two can run in parallel, because reading about storage engines while writing queries makes both sharper. Stages three and four should not be rushed, because operational confidence without change discipline is how junior administrators get their first incident. Stage six should be repeated every few months, not completed once. The skill decays, and the person who restored a database in March may be a stranger to the procedure by November.
Links Worth Bookmarking Before Your First Shift
Some catalog entries do not fit a stage but earn a permanent place in the browser bar.
SQL Noir (PAID) turns query practice into a detective story, which sounds frivolous until you notice that it forces you to build a chain of evidence across several tables. HackerRank SQL Practice (PAID) and LeetCode Database Problems (PAID) are the two interview-prep shelves, and both are worth the subscription only when you are actively applying rather than browsing. Neo4j GraphAcademy (PAID) is the graph database corner, useful when a colleague proposes a graph model and you want an informed opinion rather than a shrug.
On the free side, MongoDB University (FREE) explains document modeling well enough that you can argue about it, and Khan Academy: Intro to SQL (FREE) is the gentlest possible entry for a colleague who has never written a join. freeCodeCamp: SQL Tutorial - Full Database Course for Beginners (FREE) is a long video course that works well as background listening before a first interview. Backend Developer Roadmap (FREE) shows where the database sits inside a wider application, which is useful context when a developer asks for a change that makes no sense from the storage side. Full Stack Open (FREE) goes further and teaches you to build the application around the database, which is the fastest way to understand why an ORM generates the queries it does.
Money, Months, and the First Real Restore
The money question has a short answer for this role. Databases & Backend keeps 27 resources open at no cost, so the entire early path is covered without a card. DevOps & Cloud adds 26 more free entries, which covers the server side. Data Engineering contributes 27 free resources for the pipeline vocabulary. Software Engineering holds 30 free entries for the review and code side.
The paid entries are concentrated where structure or access matters. A paid lab subscription buys you a machine to break without consequences, which is genuinely worth money if you have no other way to get one. A paid interview-prep subscription buys a deadline and a scoreboard. A paid course buys sequence and feedback. None of them buy judgment, and none of them replace a restore you performed yourself with a timer running.
Time is the harder cost. At a part-time pace of eight to ten hours a week, stages one through four take roughly six months, and stages five and six add another three. That estimate assumes you are building something rather than watching. If your weeks are spent watching courses, the calendar stretches without limit, because watching produces familiarity and familiarity feels like progress while leaving no artifact behind.
The first results to expect are not job offers. They are smaller and more useful. You can explain what a query plan is telling you. You can install a server and connect to it. You can write a migration with a rollback step. You can restore a backup and report how long it took. Those four artifacts, written up in a short document with dates and command output, are worth more in an interview than any certificate, because they are evidence that a person has done the thing rather than read about it.
What not to expect: a first job that hands you production authority. Most people enter through a support rotation, a junior operations seat, or a developer role with database responsibility attached. That is normal, and it is useful, because the first year of real on-call teaches more than the previous two years of study. The training exists so that when the pager arrives, the answer is a procedure rather than panic.
Ways a Database Quietly Stops Being Fine
The failures in this work are rarely dramatic. They accumulate.
The first is a backup that has never been restored. A job that reports success every night proves only that a file exists somewhere. The restore is the product. If nobody has run it on a machine that was not the source, the organization has a belief rather than a backup.
The second is an index collection that grew one query at a time. Every slow report gets an index, nobody removes the old ones, and write performance degrades for reasons that take a week to find. Indexes are a budget, not a trophy.
The third is a migration tested against empty tables. A column addition that runs in twenty milliseconds on a development database can lock a table of forty million rows for six minutes in production. The test that matters uses production-shaped data, or at least production-shaped volume.
The fourth is permissions granted to a person instead of a role. It works fine until that person changes teams, and then the access remains, invisible, attached to an account nobody reviews. The fix is boring and takes an afternoon. The consequence of skipping it appears in an audit eight months later.
The fifth is monitoring that checks whether the server responds. Uptime is the least interesting signal. Replication lag, connection saturation, disk growth rate, and the age of the oldest transaction tell you about the failure before it happens.
The sixth is knowledge held in one head. A single administrator who knows the restore procedure, the password rotation schedule, and the reason for the odd replication setting is a single point of failure wearing a job title. Writing it down feels like overhead until the week that person is on holiday.
After Your First Production Database
Continue inside the catalog by going deeper in the areas this roadmap rests on: Databases & Backend, DevOps & Cloud, Data Engineering, and Software Engineering. Each guide narrows to the resources for that area, which is more useful than a general course list once you know which part of your work is weak.
Compare the neighboring roadmaps for Backend Developer, Data Engineer, and DevOps Engineer. The overlap is real. A backend developer writes the queries, a data engineer owns the pipeline, and a DevOps engineer owns the platform. The administrator owns the data's survival across all three, and the difference shows up in what each role is asked at two in the morning.
The full set of roles sits at Browse by Profession. Use it to compare rather than to collect. One concrete next action beats another tab: pick the least trustworthy database you can access, write down how you would restore it, and then find out whether you are right.
FAQ
Can I get a database administrator job without a computer science degree?
Yes, and the route is usually through adjacency. People arrive from support desks, from development roles with database responsibility, and from operations teams that kept escalating storage problems. What employers test is whether you can read a query plan, run a restore, and explain a change to somebody who does not share your vocabulary. A degree helps with some hiring filters and none of the daily work. The four areas above are the actual curriculum, and the artifacts from stages three and six are the evidence.
Should I learn PostgreSQL or a managed cloud database first?
Learn PostgreSQL first, because it is free, runs on your own machine, and teaches concepts that transfer. A managed service hides the parts you need to understand: where the files live, how the log works, what happens when the disk fills. Once you can run a local instance without help, a managed service becomes a convenience rather than a mystery. The catalog reflects this bias. PostgreSQL Documentation (FREE) and PostgreSQL Official Tutorial (FREE) are both first-class free resources, and nothing in the paid tier replaces them.
How much of this job is on-call?
More than the job description admits, especially in smaller organizations. A database has no maintenance window that does not affect somebody, so the work migrates to evenings. The practical question is not whether you will carry a pager but whether the rotation has a written escalation path, a runbook for common failures, and a rule that the person who was paged at 03:40 does not also run the 09:00 meeting. Those are organizational decisions, and a candidate can ask about them in an interview.
Is a certification worth the money for a database administrator?
It depends on what the certificate buys. A certification can clear a hiring filter at organizations that require one, and it can impose a deadline on a learner who needs one. It cannot demonstrate that you have restored a database under time pressure, and that is the question a technical interviewer actually cares about. If the budget is limited, spend it on a lab environment and a book before spending it on an exam voucher.
What do I practice on if I have no production database?
Three options, all free. Run PostgreSQL locally in a container and break it deliberately: fill the disk, kill the process mid-write, delete a table and recover it. Use DB Fiddle (FREE) for query practice that needs no install. Use Killercoda (FREE) for scenarios that give you a terminal and a broken system without touching your own machine. A practice database you are allowed to destroy teaches faster than a production one you are afraid to touch.
How long before I can be trusted with a restore?
The honest measure is not time but repetition. You are ready when you have restored the same database three times from three different backups, on a machine that was not the source, and written down the elapsed time each run. Most learners reach that point somewhere between month four and month eight of steady part-time work. After the first real restore in production, the confidence changes shape, because the cost of being wrong becomes concrete.
SkillCache Editors · Updated November 13, 2026
