Articles
Data Engineer vs Database Administrator: Responsibilities, SQL Skills, and Interviews
Compare data engineer and DBA responsibilities, SQL interviews, retry failures, database recovery, and portfolio projects to choose the work you want to own.
A data engineer typically builds and operates the paths that turn source data into usable datasets. A database administrator, or DBA, typically focuses on keeping database systems available, secure, recoverable, and performant. Both need SQL and operational judgment, but they often own different failure boundaries.
The practical distinction is this: when yesterday's orders are missing from a report, the data engineer investigates extraction, transformation, and publication; the DBA investigates database health and the effects of database changes. They may work together, and smaller teams may assign both responsibilities to the same person.
This guide compares responsibilities and original interview exercises, not guaranteed employer question sets. Choose a path by the systems and decisions you want to own, rather than assuming that shared SQL skills make the jobs interchangeable.
Who Owns the Dataset and Who Owns the Database?
Think of a dataset as a product with meaning, freshness, and consumers. A pipeline may combine application events, reference tables, and external files into a daily sales dataset. The data engineer has to explain what each row represents, when the dataset is complete, and how errors are detected and corrected.
A database is an operating system for storing and serving data, with its own durability, access, and performance requirements. A DBA may manage permissions, backup policies, upgrades, capacity, and recovery procedures. The U.S. Bureau of Labor Statistics describes database administration in terms of organizing and securing data and ensuring databases operate efficiently.
These boundaries are useful starting points, not formal industry-wide definitions. Microsoft describes data engineering around integrating and transforming data and maintaining reliable processing solutions. A particular employer might combine this work with platform administration or separate it across several teams. Always ask who is accountable when the pipeline and database disagree about success.
Compare Deliverables Before Comparing Tools
A list of tools can obscure the purpose of the job. Both candidates might name PostgreSQL, Python, and a cloud platform while doing very different work. Ask what artifact the person is expected to leave behind and what evidence shows it works.
| Responsibility | Data engineer emphasis | DBA emphasis |
|---|---|---|
| Daily output | Reliable ingestion and transformed datasets | Reliable database service and operational controls |
| Correctness question | Are rows complete, unique, and meaningful? | Are committed data and access guarantees preserved? |
| Change example | Add a source field to a published model | Upgrade the engine or change an index safely |
| Recovery artifact | Replay or backfill procedure | Tested restore and recovery procedure |
| Performance evidence | Runtime, throughput, freshness, cost | Query plans, contention, capacity, latency |
A good handoff states the overlap. For example, the data engineer owns the backfill logic, while the DBA reviews its database impact and operational window. The team agrees who can stop the work if locks or resource usage threaten other consumers.
SQL Skills Overlap, but the Questions Diverge
Both roles should understand joins, aggregation, constraints, transactions, and query plans. A data engineer may be asked to deduplicate events, preserve historical changes, or build an incremental model. A DBA may be asked to explain why a query plan changed or why a transaction is blocking unrelated work.
For a data engineering exercise, begin with grain: does one row represent an order, an order item, or an update to an order? An apparently correct join can multiply values if you combine those grains carelessly. State the expected row count and business key before writing a transformation.
For a DBA exercise, begin with the workload and evidence. A slow query does not automatically need another index. Inspect selectivity, estimated versus actual rows, existing indexes, contention, and write cost. In either role, the strongest SQL answer explains the result and its operational consequences, not merely syntax that returns plausible-looking rows.
Work Through a Retry That Duplicates Orders
Suppose a fictional source contains 100 orders with stable order IDs. A batch writes 60 rows and fails before recording success. A blind retry appends all 100 orders, producing 160 rows even though the source still contains only 100 unique orders. “Retry the job” has become a correctness bug.
The data engineer should define idempotency: repeating the same logical operation produces the intended final state without duplicating its effects. Possible designs include staging and atomically publishing a complete partition, or applying records by stable key with appropriate update rules. The choice depends on the storage engine and data contract.
Airflow's official best-practices guidance encourages tasks that can be rerun predictably and warns about duplicate-producing inserts. Applying that guidance still requires engineering detail. An upsert must define which version wins, how deletes are represented, and whether the source snapshot changes between attempts. A DBA may help validate constraints and transaction behavior, but those controls cannot invent the correct business meaning.
A Late-Arriving Record Tests Pipeline Design
Imagine a daily revenue dataset closes at midnight, but an order placed at 23:58 arrives at 00:07. Filtering only on the current arrival date can place the order in the wrong business day or omit it from an already published partition. First distinguish event time from ingestion time.
A candidate could propose revisiting a recent window and replacing affected partitions, provided the source supports a consistent reconstruction. Another design might process corrections as explicit changes. Explain how consumers learn that a previous total changed and whether the system records both original publication and corrected values.
The DBA's contribution may include ensuring that the chosen update pattern does not cause excessive locking or overwhelm storage. The data engineer remains responsible for the meaning of the corrected dataset. This exercise reveals why successful SQL execution is insufficient: the database can faithfully store a result that violates the reporting contract.
A Restore Exercise Tests a Different Kind of Ownership
Consider a PostgreSQL recovery drill with a base backup from 00:00 and an accidental change at 10:03. The proposed target is 10:02:59. The DBA must establish whether the required write-ahead log, or WAL, is available continuously from the backup through the target and whether the backup is usable.
PostgreSQL's official documentation explains point-in-time recovery using a base backup and archived WAL. A timestamp alone is not a recovery plan. Restore into an isolated environment, select the appropriate recovery target, and verify the resulting data before considering a cutover. Actual target settings and inclusive boundaries must match the incident.
The data engineer then checks downstream consequences. Did a pipeline already export the incorrect values? Will replaying data recreate the bad change? Which published datasets need correction? Restoring a database does not rewind every external effect. The two roles meet at this boundary, where database recovery and end-to-end data correctness require separate evidence.
Explain Recovery Objectives Without Promising Them
Recovery point objective, or RPO, expresses tolerable data loss. Recovery time objective, or RTO, expresses tolerable downtime. They are objectives to design and test against, not numbers guaranteed by the existence of a backup schedule.
Suppose a team wants an RPO of five minutes and an RTO of thirty minutes. A daily backup alone does not establish either outcome. The plan must account for the recovery mechanism, accessible recovery data, detection, restoration, validation, and reconnecting dependent systems. A timed drill supplies better evidence than a configuration screenshot.
For pipeline work, a related objective might be a dataset available by 08:00, with a documented correction window. Ask whether a late publication is preferable to a partially complete one. A candidate who distinguishes the database objective from the dataset objective can discuss trade-offs without promising that one successful subsystem automatically satisfies the whole business process.
Diagnose the Same Slow Report From Both Sides
An interview prompt says a report that normally finishes quickly now takes several minutes. Start by asking what changed: data volume, query text, schema, load timing, database configuration, or another workload. Establish whether the delay is query execution, waiting, data loading, or report rendering.
The data engineer might discover that a transformation began joining orders to multiple customer-history rows. The DBA might discover blocking from a long-running transaction. Both findings can be true at once. More hardware could mask symptoms while leaving an incorrect result untouched.
| Observation | First hypothesis to test | Useful evidence |
|---|---|---|
| Row count grows unexpectedly | Join fanout or duplicate input | Counts by business key before and after joins |
| Queries wait without progressing | Blocking or resource contention | Wait events and active transactions |
| Runtime rises after data growth | Plan or access-path mismatch | Plan estimates and actual row counts |
| Report is fast but stale | Pipeline freshness failure | Source timestamps and publication status |
State what would disprove your hypothesis. This keeps the investigation collaborative and prevents title-based assumptions about who caused the problem.
Build a Portfolio Around a Controlled Failure
A data engineering portfolio can begin with two small source files and a relational target. Include duplicate records, a late update, and a source schema change. Show the expected output, rerun behavior, data-quality checks, and a backfill procedure. The interesting artifact is the explanation of correctness under those failures.
A DBA portfolio can use a disposable database environment with sample data. Demonstrate backup and restore, a constrained access role, and a query investigation. Record setup, observations, recovery verification, and cleanup. Keep destructive experiments isolated from real data and avoid describing an untested backup as a recovery capability.
For either path, show how another person could reproduce the result. A before-and-after screenshot without assumptions or commands proves little. A short incident report that separates symptoms, evidence, intervention, and verification gives an interviewer a concrete basis for follow-up. Include a case where the first suspected cause was wrong.
Read Job Descriptions for Operational Boundaries
For data engineering roles, ask about source ownership, orchestration, modeling, batch versus streaming work, data quality, and consumer expectations. Find out whether engineers own production incidents and whether they can influence source contracts. A role that mostly maintains reports may differ from the pipeline-building work you expected.
For DBA roles, ask about engine families, managed versus self-managed services, upgrades, access reviews, capacity, restore drills, and on-call responsibilities. Managed infrastructure changes the division of labor; it does not by itself explain who verifies recovery or approves database changes.
Avoid drawing salary or demand comparisons from mismatched occupational categories. The BLS page groups database administrators and architects in some sections, and data engineering is not a directly interchangeable category. For an actual career decision, compare specific openings and responsibilities. Title-level market generalizations are less useful than knowing what the team needs you to operate on your first incident.
Choose the Failure You Want to Become Good at Solving
If you enjoy tracing how source events become trusted information, data engineering may be the stronger fit. If you enjoy preserving database guarantees through load, changes, and outages, DBA work may be more appealing. Neither path removes the need to communicate with users or reason about business consequences.
A useful final exercise is to explain the 100-order retry and the point-in-time restore aloud. For each, name the invariant, the failure, the evidence, the recovery action, and what remains outside your control. Notice where your explanation becomes vague; that is a better study target than another tool checklist.
Career transitions can build on the overlap. A DBA can demonstrate transformation semantics and pipeline testing; a data engineer can demonstrate engine operations and tested recovery. Make the additional responsibility visible through a small working example. The goal is to show trustworthy ownership of a larger boundary, not simply add another job title to a resume.
Sources and Further Reading
- U.S. Bureau of Labor Statistics: Database administrators and architects
- Microsoft Learn: Data engineer career path
- Apache Airflow: Best practices
- PostgreSQL: Continuous archiving and point-in-time recovery
Research checked September 24, 2026. Role boundaries vary by employer. Recovery details depend on database version and configuration; all incident figures above are illustrative exercises, not service guarantees.