The DBA of old spent mornings checking tablespaces and evenings applying patches. On Amazon RDS or Azure SQL Database, the provider now does a good share of that, yet the pages still arrive: a query plan flips after a statistics update, a schema change locks a busy table at noon, or a developer’s new service opens more connections than the instance can accept. Database administrator skills have moved up the stack, from looking after a server towards looking after how data, code and cost interact in production.
That makes the role harder to assess, since a CV full of engine names tells you little about judgement. This post covers nine technical skills with checks you will not find in a standard interview pack, then the working habits behind a dependable DBA, what is rising and falling in value, a matrix by level and a way to assess all of it on your own systems.
Core technical skills for a database administrator
Recovery design and proof
Recovery point and recovery time objectives are business promises, and a DBA turns them into schedules, retention and storage. Strong DBAs also know that a backup taken from a corrupt database is a faithful copy of the corruption, so they run integrity checks such as DBCC CHECKDB, RMAN VALIDATE or pg_amcheck. How to check it: give them a database size, a restore throughput figure and a recovery time target, then ask whether the target can be met. Look for someone who includes log replay and the time needed to verify the data, and who treats a replica as no defence against a bad delete.
High availability and quorum
Data Guard, Always On availability groups, Patroni and MySQL group replication solve the same problem in different ways. The skill is understanding what each gives up when the network fails, and the difference between synchronous and asynchronous commits. How to check it: describe two data centres that lose contact while both remain running. Ask what stops each side from accepting writes. Good candidates raise quorum, a witness or observer, fencing and the data loss that an asynchronous failover can bring.
Index strategy
Adding indexes is easy, while knowing which ones to remove takes experience, because every index slows writes and consumes memory. Strong DBAs think about column order, covering indexes and partial or filtered indexes. How to check it: show a composite index on status and created date, plus a slow query that filters only by date. Ask why the index helps so little and what they would change. Then ask how they would find indexes that nobody uses, on your engine.
Connections and pooling
Autoscaled application pods can open connections much faster than a database can serve them. DBAs need to understand pool sizing, memory per connection and tools such as PgBouncer. How to check it: ask why a PostgreSQL service failed right after developers doubled the pod count, though CPU stayed low. Then ask what session features can break under transaction pooling. Session settings, session-level advisory locks and hand-written PREPARE are the kind of detail that shows real use, since recent PgBouncer versions track protocol-level prepared statements.
Schema change under load
Most self-inflicted database incidents begin with a migration. Good DBAs know what each change locks on their engine and use tools or features such as CREATE INDEX CONCURRENTLY, gh-ost or online index operations. How to check it: explain that a developer plans a quick ALTER TABLE on a busy PostgreSQL table during the day. Ask what could freeze the application even if the change itself is fast. The answer you want is a lock queue: a waiting ALTER holds up every query behind it, which is why experienced DBAs set a lock timeout and retry.
Data lifecycle and partitioning
Tables grow until the maintenance around them hurts. Partitioning, archiving and retention rules keep them manageable, and privacy law gives companies another reason to stop keeping data forever. How to check it: ask how they would remove old rows from an enormous live table. Dropping a partition is ideal where the design allows it. Otherwise, listen for small batches, pauses for replication and a plan for the bloat or log growth that follows.
Security beyond read access
Encryption at rest, TLS, audit trails and role design all sit with the DBA. So does the awkward clean-up of applications that connect with far too much privilege. How to check it: say an application has always connected as the database owner. Ask how they would move it to a least-privilege account without an outage. Good answers begin by observing what the application really does, then create roles, test and roll out with a way back.
Migration between engines
Moves from Oracle to PostgreSQL are common, and the schema is the easy part. Tools such as ora2pg and AWS Database Migration Service help with conversion and data transfer, while stored code and behaviour need careful human attention. How to check it: ask what might change in application behaviour after such a move. Someone who has done this will know that Oracle treats an empty string as NULL, and PostgreSQL does not, and will have further stories about sequences, date handling and PL/SQL packages.
Managed service fluency
Running on Amazon RDS, Aurora or Azure SQL Database changes the toolkit. You lose operating system access, you work through parameter settings and provider metrics, and you pay for many decisions directly. How to check it: ask what a point-in-time restore does on RDS. It creates a new instance, so the DBA must also plan endpoints, parameters and how applications switch over.
Working skills that separate good from average
- Partnering with developers. A DBA who only says no gets bypassed. Strong ones review migrations early and explain the cost of a design.
- Measuring before changing. Good DBAs capture a baseline, change one thing and compare.
- Staying calm in a live restore. Everyone is watching and the temptation to rush is strong. Dependable DBAs pause to confirm the target, take a copy of the current state and narrate each step.
- Thinking in business terms. Not all data deserves the same protection or spend. A good DBA can explain to a finance leader what a tighter recovery target will cost and what it buys.
DBA skills that matter more in 2026, and less
Mattering more. PostgreSQL has become a default choice for new systems and a common destination for migrations, which raises demand for people who know its internals. Vector search inside existing databases, through pgvector for example, means DBAs now meet embedding columns and approximate indexes with very different memory needs. Cloud bills make storage, provisioned performance and replica counts into DBA concerns. In India, the Digital Personal Data Protection Act pushes teams to know where personal data sits and how long it stays. AI assistants produce plausible queries in volume, so reviewing machine-written SQL before it reaches a busy table is a growing duty.
Mattering less. Hand-tuning disk layouts and installing engines on bare metal matter less wherever managed services and fast cloud storage are in use. On managed services, routine minor patching is largely automated. Single-engine loyalty also counts for less, because few estates now run one database product alone.
Database administrator skills matrix by level
| Skill area | Junior | Mid-level | Senior |
|---|---|---|---|
| Recovery | Verifies backups, follows runbooks | Runs restores and integrity checks | Designs to business recovery targets |
| High availability | Monitors replication health | Performs and tests failover | Chooses topology and quorum design |
| Performance | Finds slow queries | Tunes indexes and statistics | Advises on data models and hardware |
| Schema change | Runs reviewed scripts | Plans low-lock migrations | Sets the change standard for teams |
| Security | Handles access requests | Manages roles, audit and encryption | Designs access model, leads compliance work |
| Cloud and cost | Reads provider metrics | Runs managed instances and sizing | Shapes hosting choices and spend |
| Automation | Uses existing jobs | Scripts health checks and maintenance | Manages the fleet through code |
How to assess DBA skills in a hiring process
Run these after the basics are covered. The database administrator job description deals with framing the post, and with early questions on recovery and tuning. The exercises below go further, and all of them work best on your chosen engine.
- Review a real migration script. Give them a sanitised change from your backlog and ask whether it is safe on a busy table.
- Read a monitoring snapshot. Share wait statistics or an activity report from a bad hour. Ask what they conclude, and what else they would want to see before acting.
- Run a timed recovery rehearsal in a sandbox. Ask for a restore to a named moment, followed by proof that the data is right. The proving step often separates careful people from fast ones.
- Ask about an estate they inherited. What did they check in their first days, and what did they leave alone?
Keep a boundary in mind while assessing. A data engineer moves data for analytics, and a backend developer writes the queries, so stories about pipelines or feature work should not stand in for production database ownership. Red flags on a CV: four engines listed as expert; “performance tuning” with no named outcome; no mention of a restore; only development databases; and managed services presented as if they removed all responsibility.
Frequently asked questions
Can a DBA switch from one engine to another?
Yes, because recovery, concurrency and indexing are shared ideas. The tooling and failure modes differ, though, so an Oracle DBA moving to PostgreSQL needs time with vacuum, replication and extensions. For a critical production role, hire someone with direct experience of your engine.
Should a DBA also know MongoDB or other NoSQL stores?
Only if you run them. Replication, sharding and backup concepts carry over, but operating MongoDB, Cassandra or Redis well takes specific practice. Do not assume that a relational specialist will cover them without learning time.
How much operating system knowledge does a DBA need?
On self-managed databases, a good deal: storage, memory, file systems and process behaviour on Linux or Windows Server. On managed services it matters less day to day, but understanding it still helps when interpreting provider metrics.
Will AI tools replace query tuning?
They can already suggest indexes and rewrites, and they are useful for a first look. They rarely know your data distribution, write load or release plans, so a person still has to judge the suggestion and test it. That judgement is what you are paying for.
Zilo AI screens on real outages, restores and upgrades, plus scripting, and you can hire database administrators in India through us on contract, contract-to-hire or permanent terms. You can see related roles on the IT talent page, or let us know your engine and hosting setup to begin a search.