Remote DBA Services: What You Actually Get and When They Make Sense

Remote DBA services boil down to one idea: instead of hiring a database administrator, you get a team of them working on your databases over secure remote access. Simple on paper. Doing it well is harder. Some providers become a real part of your engineering team. Others are a ticket queue with a phone number. This guide covers what you should actually get, who benefits most, and how to choose.

Who actually needs a remote DBA

In our experience, the companies that get the most out of remote DBA services fall into a few groups:

• No DBA at all. Developers run PostgreSQL or MySQL "on the side". It works until the database becomes the bottleneck, a migration is due, or something breaks at night.
• One DBA, no backup. One person can't be on call every night of the year, take holidays and also run projects. A remote team covers the gaps and the 3 a.m. pages.
• "We're on managed cloud, so we're fine." Managed services take a lot of work off your plate, but not all of it. AWS is explicit about this: in its RDS shared responsibility model, query tuning stays with the customer, and "monitoring and tuning are highly individualized processes that you own for your RDS databases." Application optimization is listed as the customer's job in every deployment model.
• A big change is coming. A migration, a major version upgrade, high availability, a move between clouds. You need deep expertise for months, not forever.

What good remote DBA services include

A remote DBA engagement worth paying for covers three kinds of work. If a provider only talks about the third one, be careful.

1. Proactive work (most of the value)

• Monitoring and alerting tuned to your system: replication lag, locks, disk growth, connection saturation, vacuum health, slow queries.
• Backups that are tested by actually restoring them, on a schedule.
• Regular query and index reviews, so performance doesn't degrade quietly.
• Capacity planning: when will you run out of disk, IOPS or memory at the current growth rate?
• Patching and version upgrade planning, so you don't end up on an unsupported release.
• Security reviews: users, roles, network exposure, encryption, audit settings.

2. Incident response

When something breaks, a senior DBA who already knows your system should be on it quickly. The response time for critical incidents must be written into the agreement, including nights and weekends. If you've just found this page in the middle of an outage, read our emergency DBA guide first and the rest of this article later.

3. Projects

Migrations, upgrades, HA setups, sharding, moving between engines or clouds, cost reduction. Cloud bills are a common trigger: right-sizing instances and storage often pays for the DBA work itself (we describe the usual levers in how to reduce AWS RDS and Aurora costs).

What a remote DBA can't do for you

Honesty helps both sides here. A remote DBA can tune queries, design indexes, fix configuration and run the operational side. They can't on their own fix an application that runs 400 queries per page, or a data model that fights the business it is meant to describe. Those fixes need your developers. The best results come when the DBA works with your team, reviews schema changes before they ship and explains the "why", instead of quietly patching symptoms.

Engagement models: retainer, project, hourly

1. Monthly retainer. A fixed number of hours or a defined scope each month, including monitoring and incident response. Best for production systems you depend on. Predictable cost, and the DBA builds real knowledge of your setup.
2. Project-based. A fixed scope and price for a migration, an audit or an HA build. Good when you know exactly what needs doing.
3. Hourly / ad hoc. Flexible, fine for occasional questions. The catch: without a retainer, nobody has agreed to be available at 3 a.m., and each request starts from less context.

Many teams combine them: a project to fix the urgent things, then a smaller retainer to keep them fixed.

Onboarding: what the first weeks should look like

1. Discovery call. What runs where, what hurts, what is planned.
2. Access setup. VPN or bastion host, named accounts, least privilege.
3. Health check. Configuration, backups, replication, security, the top resource-consuming queries. You should get a written report with priorities, not a sales deck.
4. Monitoring and alert routing, so the right people get paged for the right things.
5. Runbooks for your typical failure modes, written down before they happen.

At AG Data the health-check audit happens within the first week, and the action plan comes out of it. Weekly updates follow.

Security and access: non-negotiables

• Every person has their own account. No shared "dba" login.
• Least privilege: full admin only where it's really needed, read-only for monitoring.
• Access through VPN or a bastion with MFA, logged and revocable in minutes.
• Production changes go through an agreed process: announced, reviewed, reversible.
• In the EU, if the DBA can see personal data, they act as a processor and you need a data processing agreement as required by Article 28 GDPR. An NDA alone is not enough.

Red flags when choosing a provider

• A different engineer every time. Context is everything in database work. You want the same person, or a small team, who knows your system.
• No response time in writing, or one that only applies during office hours.
• "We support every database." Ask which engines they run in production every day.
• No written reports. If you can't see what was done and why, you can't judge the work, and you can't leave.
• Changes in production without review or without a rollback plan.
• Lock-in by obscurity. Monitoring, scripts and documentation should belong to you and stay with you if you switch providers.