Need an Emergency DBA Right Now? Read This Before You Touch Anything

If you are reading this because you typed "urgent DBA" or "need a DBA immediately" into Google, the database is probably on fire right now. So let's skip the introduction. Emergency DBA support is worth calling when your own team has stopped making progress, and it is worth the most when you have not made things worse before help arrives. That second part is what this page is about.

First: stop. Do not do these things

A database outage is bad. It gets much worse when, in the hour before help arrives, someone under pressure tries something they read on a forum. The PostgreSQL community wiki puts it plainly: "People often destroy potentially recoverable data by trying to repair it." Before anything else, rule these out:

• Do not delete files from the data directory to free disk space. Not pg_wal, not pg_xact, not "old-looking" files. In PostgreSQL those files are the database. On MySQL, never rm binary logs either; use PURGE BINARY LOGS, and only after checking which logs your replicas still need (MySQL documentation).
• Do not run pg_resetwal because a blog post told you to. The official documentation calls it a last resort and warns the database may afterwards contain inconsistent data. It can get the server up. It can also quietly lose committed transactions.
• Do not keep restarting the server hoping it comes up next time. Each attempt can overwrite logs you need and, with a full disk, can make the state worse.
• Do not fail over blindly. Promoting a replica that is hours behind, or doing it while the old primary is still accepting writes, gives you two diverging databases. Merging those later is painful.
• Do not restore a backup over the only copy of the broken database. Restore somewhere else. The broken one may still hold the last hours of data that the backup doesn't have.
• Do not run VACUUM FULL, REPAIR TABLE or mass DELETEs as a performance fix in the middle of an incident. These take heavy locks or generate lots of writes, which is the opposite of what a struggling server needs.

The next 30 minutes: what actually helps

1. Stop the bleeding, not the database. Pause batch jobs, cron tasks, ETL and anything else non-essential. Put the app into maintenance mode if you can. Less load buys time.
2. If you suspect corruption, copy the files first. The PostgreSQL wiki's advice is to stop the server and take a file-system-level copy of the whole data directory before any repair attempt (PostgreSQL wiki: Corruption). The same logic applies to every engine. A disk or cloud volume snapshot also works. That copy is your undo button.
3. Write down the timeline. When did it start? What changed in the last 24 hours: a deploy, a migration, a config change, a new index, an OS update, a cloud maintenance event? Very often the cause is somewhere in that list.
4. Save the evidence. Database error log, the last few screenshots from monitoring (CPU, disk, connections, replication lag), the exact error text that users or the app see. Copy, don't paraphrase.
5. Pick one person to talk to the outside world. Engineers fixing the problem shouldn't also be answering "is it back yet?" every five minutes.

Situations where you really do need a DBA immediately

Not every incident needs outside help. A deploy that broke one query can usually be rolled back by your developers. These are the cases where waiting usually costs more than calling:

• the primary will not start, or starts and crashes again;
• errors mentioning corruption, invalid pages, checksums or "could not read block";
• disk full on the database server and nobody is sure what is safe to remove;
• replication broken and automatic failover failed, or you are not sure which node has the latest data;
• PostgreSQL refusing writes with a transaction ID wraparound message;
• you need to restore, and nobody has ever tested the backups;
• signs of a security incident: unknown accounts, dropped tables, ransom notes.

The backup point deserves a moment of honesty. If the restore has never been rehearsed, you don't really know whether you have a backup. We wrote about that in database backup and restore testing, but during an outage the useful question is simpler: where are the backups, how old is the newest one, and has anyone ever restored one?

How to hand over to an urgent DBA without losing an hour

When an outside DBA joins mid-incident, the first stretch of time goes on getting access and context. You can shrink that a lot by having this ready before the call ends:

• Engine and version (PostgreSQL 16.4, MySQL 8.0, MariaDB, SQL Server, Oracle...), and where it runs: own hardware, VM, RDS, Aurora, Cloud SQL, Kubernetes.
• Topology: primary, replicas, poolers, load balancers, failover tooling (Patroni, Orchestrator, cloud managed).
• Access: a temporary account, VPN or bastion host details, and who approves it. Use MFA where you can and revoke it afterwards.
• The timeline and evidence from the previous section.
• Backup location and age.
• Someone who can make decisions: "can we lose the last 10 minutes of data to be back online now?" is a business call, not a DBA one. Somebody with authority needs to be reachable.

How to choose emergency DBA support (ideally before you need it)

Search results for "emergency DBA" are full of agencies that will take your ticket at 3 a.m. and assign it to someone at 9. Ask these questions directly:

1. Who picks up? A senior DBA, or a dispatcher who opens a ticket?
2. What is the actual response time for a critical incident, at night and at weekends? Get it in writing.
3. Which engines do they really run in production? "We support all databases" usually means "we support one well".
4. How is emergency work billed? Hourly, a fixed incident fee, or included in a retainer? Avoid surprises when you are least able to negotiate.
5. Do you get a written report afterwards: root cause, what was changed, what to fix so it doesn't happen again?

The best emergency DBA is the one who already knows your system. A provider who has your topology documented and access agreed in advance can start fixing within minutes instead of starting with "so what do you run?". How that looks from the inside is described in what a 15-minute database incident response actually looks like.

After the fire

Once the database is back, the temptation is to move on. Don't, at least not right away. Write the timeline down while people still remember it. Fix the monitoring gap that let the problem grow unnoticed. Test a restore. And decide whether you want to be doing an unplanned 2 a.m. search for a DBA again next time. For one manufacturing client we went from a failed on-premises Oracle server with no clear recovery path to a recovered system running on cloud infrastructure within 24 hours of first contact (case study). Getting there was possible because the team called early and had not tried to "repair" anything first.