A shortlist in 72 hours, contributing inside two weeks, and a 30-day guarantee if the fit is wrong.
72-hour shortlist · 30-day replacement guarantee · Month-to-month
Database administration is the clearest example in this industry of work that is invisible when done well and catastrophic when not done at all.
Nobody praises a quarter with no incidents. Nobody notices that a schema change went out without locking a table, or that autovacuum kept up, or that the replica stayed close enough behind that read-after-write worked. So the role gets cut, absorbed into a backend team, or assumed away entirely on the grounds that the database is managed now.
The single most common finding when we place a DBA into a team that has not had one is a backup that has never been restored. Backups are running. Somebody checks that the job succeeded. Nobody has taken the most recent one, restored it into a clean instance, and timed how long it took — which means the recovery time in your continuity plan is a guess, and possibly a wrong one.
The failure is not that backups are missing. It is that "backup" and "restore" were treated as the same thing.
Every one of these is invisible while it is working, which is exactly why it goes unstaffed.
Whether they have timed a real restore against a stated recovery objective, or only confirmed that backup jobs report success.
Which schema changes take blocking locks, and how to make the same change safely on a large table that is being written to.
Reading an execution plan and acting on it, including knowing when the answer is to remove an index rather than add one.
Vacuum and statistics tuning for the actual workload. The cause of most gradual slowdowns nobody can attribute.
Lag under load, read-after-write consequences, and whether they have tested a failover outside a planned window.
A live conversation in English, every time. Much of this role is persuading a team to change how it ships schema.
Database problems tend to arrive in one of two shapes: a slow decline nobody attributes correctly, or a single very bad afternoon.
The slow decline is usually maintenance. In Postgres, tables that take heavy updates need autovacuum to keep up, and on a busy table with default settings it often does not. Dead rows accumulate, the table and its indexes bloat, plans get worse, and queries that were fast in March are slow in September with no code change to blame. Teams chase the application for weeks. The fix is tuning that somebody should have owned from the start.
The bad afternoon is usually a migration. A schema change that looks harmless takes a lock the whole application needs, and in Postgres it queues behind one long-running transaction — so the migration waits, and every query arriving after it waits too. Connections pile up until the pool is exhausted. From the outside the entire product is down, and the deploy that caused it changed one column. Somebody who has done this before writes the same change so it takes the lock briefly or not at all, and builds indexes without blocking writes.
Replication lag is the quiet third case. Reads go to a replica for scale, the replica falls behind under load, and a user updates something and immediately sees the old value. It is intermittent, it never reproduces in staging, and it gets logged as a frontend caching bug for months.
DBA (3–5 years). Runs backups, monitoring and routine maintenance. Comfortable reading a query plan and adding an index. Follows an established runbook rather than writing one.
Senior DBA (5–8 years). Owns capacity, replication and failover, designs migrations that do not take disruptive locks, tunes for the workload rather than to a checklist, and tests restores on a schedule.
Database Architect (8+ years). Chooses engines and topology, sets the sharding or partitioning strategy, owns recovery objectives with the business, and can say plainly when a workload does not belong in a relational database at all.
Performance work. An application that got slower without a clear cause. The most common request, and usually the fastest return.
Backup and recovery assurance. Establishing that you can actually restore, and how long it takes. Bounded work with an unambiguous outcome.
Migration and upgrade. Version upgrades, moving to managed hosting, or engine changes. Rehearsal is most of the job.
High availability design. Replication, failover, and testing that failover works when it is not a drill.
Support alongside a backend team. Part-time cover for teams whose developers own the schema. Frequently paired with data engineers where analytics loads share the estate.
Week one. They restore your most recent backup into a scratch instance and time it. That single exercise answers more questions than a fortnight of review, and on estates that have not had a DBA it frequently fails outright. Expect questions about recovery objectives, who is on call, and what your slowest queries are.
Weeks two to four. A measured improvement with a number attached — a slow query rewritten or indexed, maintenance settings tuned to the workload, a migration pattern documented so the next schema change does not lock the application. Expect a written recovery procedure that somebody other than them could follow.
The warning sign is a DBA who only adds indexes. Indexes fix reads and tax every write, and an estate that has accumulated them for years is often slower for it. Somebody who proposes removing a few, having checked which are unused, is thinking about the whole workload rather than the ticket in front of them.
Assuming a managed database removes the role. Managed hosting takes over patching, hardware and the mechanics of backup. It does not tune your queries, design your migrations, size your connection pool, or test that a restore meets the recovery time you promised. The work shrinks; it does not disappear, and the belief that it has is why estates drift.
Never testing the restore. A backup job reporting success proves a file was written. Restore it quarterly into a clean instance and time it. Teams that do this find problems in a controlled window; teams that do not find them during an incident, which is the only time the answer matters.
Letting every developer change the schema unreviewed. Not because developers are careless, but because the locking behaviour of a given change under load is specialist knowledge that is easy not to have. One reviewer who knows which migrations are safe prevents most database-caused outages.
Hiring a DBA when the problem is the data model. A structure that fights its access patterns cannot be tuned into shape. Sometimes the honest answer is a schema change or a different store for one workload, and a good candidate will tell you that in the first month rather than quietly adding indexes for a year.
Rates depend on engine, seniority, and engagement length. Tell us the role and we will give you a firm number.
Tell us the role and we will send a shortlist within 72 hours.
Tell Us the RoleTell us the role. Three to five profiles within 72 hours.