Database Administrator (DBA) Interview Questions and Answers

What led you to specialize in database administration?

I was drawn to the fact that databases sit at the heart of everything: if they are slow or down, the whole business stops. I like the mix of deep technical problem-solving and the responsibility of protecting data that the company cannot afford to lose. Over time I found real satisfaction in tuning a query from minutes to milliseconds or designing a backup strategy that quietly saves the day. That combination of high stakes and craftsmanship is what keeps me in this field.

What database platforms have you managed and at what scale?

I have run production PostgreSQL and SQL Server environments, plus some MySQL, ranging from single instances to clustered setups handling terabytes and thousands of transactions per second. I have managed high-availability configurations with replication and automatic failover, and I have supported both OLTP systems and reporting replicas. I am comfortable across on-premise and cloud-managed offerings like RDS. My depth is strongest in PostgreSQL, but the core disciplines of tuning, backup, and HA transfer across engines.

How do you stay calm and effective during a production database incident?

I rely on preparation and a clear head. Because I have runbooks and tested recovery procedures, an incident becomes a process to execute rather than a panic. During the event I focus on stabilizing first, communicating status clearly, and avoiding rushed changes that could make things worse. After it is resolved I run a blameless postmortem to fix the root cause, because a well-handled incident should make the system stronger than before.

What kind of database environment do you want to work in next?

I want an environment where reliability and data integrity are genuinely valued and where I can invest in automation rather than firefighting all day. I enjoy meaningful scale and complexity, high transaction volumes, replication, and demanding uptime targets, because that is where the discipline of good administration pays off. I also like working closely with developers to shape schemas and queries before they hit production. A place that treats the DBA as a partner, not just a break-glass resource, is what I am after.

How do you approach diagnosing and fixing a slow query in production?

I start with the execution plan to see whether it is doing a sequential scan, a bad join order, or an expensive sort, and I check the actual versus estimated rows to spot stale statistics. Common fixes are adding or correcting an index, rewriting the query to be sargable, or updating statistics so the planner makes better choices. I confirm the improvement with real timing and I watch that a new index does not hurt write performance. I also look at whether it is a one-off or a pattern worth a structural fix.

Walk me through your backup and recovery strategy.

I design around recovery objectives: how much data loss is acceptable and how fast we must be back up. That usually means full backups on a schedule plus continuous transaction log or WAL archiving so I can do point-in-time recovery. Critically, I test restores regularly, because a backup you have never restored is just a hope, not a strategy. I also keep copies off the primary infrastructure and document the recovery steps so anyone on the team can execute them under pressure.

How do you design and maintain a high-availability setup?

I choose the HA pattern based on the recovery time and data-loss tolerance, typically synchronous or asynchronous replication with automatic failover to a standby. I make sure the failover is actually tested through regular drills, not just configured, because untested failover often fails when it matters. I monitor replication lag and set up alerting before it becomes a problem. I also plan for the application side, connection routing and retry logic, since HA at the database is useless if the app cannot reconnect cleanly.

How do you approach indexing strategy without hurting write performance?

I index based on actual query patterns from the workload, not guesses, so I look at which predicates and joins appear most and cost the most. I favor covering and composite indexes where they eliminate expensive lookups, but I am disciplined about removing unused or redundant indexes because every index taxes inserts, updates, and storage. I monitor index usage statistics over time. The goal is the minimum set of indexes that serves reads well while keeping writes healthy.

How do you handle database security and access control?

I apply least privilege rigorously, granting roles the minimum permissions needed rather than broad admin access, and I use role-based grants so access is manageable. I encrypt data in transit and at rest, keep credentials out of application code using a secrets manager, and audit access to sensitive tables. I stay current on patching because unpatched database engines are a common breach vector. I also separate duties so no single person can both change data and erase the audit trail of that change.

How do you plan and execute a schema change or migration on a large production table with no downtime?

I avoid blocking operations by using online techniques: adding nullable columns rather than rewriting the table, creating indexes concurrently, and backfilling data in small batches to avoid long locks. For risky changes I use a tool that does the migration on a shadow copy and swaps it in, or an expand-contract pattern where old and new schema coexist during the rollout. I always test on a production-like dataset first and have a rollback plan. Communication with the app team on deploy timing is part of the plan, not an afterthought.

How do you set up monitoring and alerting for your databases?

I monitor the vital signs: query latency, connections, replication lag, cache hit ratios, lock waits, disk space, and backup success. I set alerts on leading indicators like rising replication lag or shrinking free space so I can act before an outage, rather than only alerting after something breaks. I keep dashboards for trend analysis so I can spot slow degradation. Tuning thresholds to avoid alert fatigue is important, because an alert nobody trusts is worse than no alert.

How do you handle capacity planning and scaling as data grows?

I track growth trends in data volume, connections, and query load so I can forecast when we will hit limits rather than being surprised. Depending on the bottleneck I scale vertically, add read replicas to offload reporting, introduce partitioning for very large tables, or archive cold data. For write-heavy scaling I evaluate sharding carefully, since it adds real complexity. I prefer to buy runway with tuning and archiving before reaching for architectural changes that are hard to reverse.

How do you collaborate with developers to prevent database problems before they reach production?

I review schema changes and heavy queries before they ship, looking for missing indexes, N-plus-one patterns, and queries that will not scale. I provide guidelines and sometimes a shared query-review checklist so good practices are the default. I make a production-like environment available so developers can test against realistic data volumes rather than a tiny sample. Being a helpful partner early is far cheaper than being the person paged at 2 a.m. because a bad query hit production.

Tell me about a serious database incident you resolved.

A primary database ran out of disk space during peak hours because a runaway logging table had grown unchecked, and writes started failing. I stabilized it first by freeing space and throttling the offending process, which restored service within about twenty minutes. Then I traced the root cause, added disk-space alerting well below the threshold, and set up automated cleanup and partitioning for that table. The postmortem changes meant we never hit that specific wall again.

Describe a time you had to recover data after a failure or mistake.

A deployment script accidentally deleted rows from a production table due to a missing WHERE clause. Because I had continuous log archiving, I was able to do a point-in-time restore to a moment just before the deletion on a separate instance, extract the affected rows, and merge them back without a full outage. We were fully recovered within a couple of hours with no lasting data loss. It reinforced my rule that tested point-in-time recovery is non-negotiable.

Tell me about a time you disagreed with a developer or manager about a database decision.

A team wanted to store a large, frequently changing JSON blob in a single row and query into it constantly, which I knew would cause bloat and slow scans. Rather than just refusing, I showed them benchmark results comparing their approach with a normalized design under realistic load. The numbers made the case for me: the normalized version was significantly faster and lighter. We compromised on a hybrid, and they appreciated that I brought data rather than dogma.

Describe a time you automated a repetitive or error-prone task.

I was spending hours each week manually checking backup completion and running restore validations across many instances. I scripted the whole flow: automated backup verification, periodic test restores into a scratch environment, and an alert if any step failed. It freed up a large chunk of my week and, more importantly, turned backup validation from something we hoped happened into something we could prove happened. That automation later caught a silently failing backup we would otherwise have missed.

The primary database goes down during peak traffic. Walk me through your response.

My first priority is restoring service, so I would confirm the failure, trigger failover to the standby if HA is in place, and verify the application reconnects and traffic recovers. I would communicate status to stakeholders immediately so the business knows what is happening and the expected timeline. Only after service is stable would I investigate the root cause on the failed node, preserving logs and state for the postmortem. Afterward I would run a blameless review and fix whatever allowed a single failure to cause an outage.

A developer wants to run a large ad-hoc query against the production database during business hours. How do you respond?

I would not simply say no, but I would avoid letting a heavy query degrade production for everyone. I would first understand what they need and offer to run it against a read replica or a reporting instance so it does not compete with transactional load. If it must run on primary, I would review it for efficiency, add appropriate limits, and schedule it for a low-traffic window. The goal is to unblock them safely rather than protect the database by being an obstacle.

You notice replication lag steadily increasing on a critical replica. What do you do?

I would investigate the cause before it turns into a stale-data or failover risk, checking whether it is a long-running transaction on the primary, an I/O or CPU bottleneck on the replica, or a spike in write volume. Depending on the finding I might tune the replica's resources, break up the offending transaction, or temporarily reduce write pressure. I would keep stakeholders informed if the lag affects reporting accuracy. Once resolved I would adjust alert thresholds so we catch this earlier next time.