Frequently asked questions
The questions buyers ask before they hand over the database.
Cost versus hiring in-house, response time SLAs, migration risk, security and compliance, and which platforms are covered — answered plainly, without a sales call.
Working with us
What an engagement actually looks like.
How the relationship is structured, who you talk to, and what it takes to get started.
What is a fractional or remote DBA, and how is it different from hiring a consultant for a one-off project?
A fractional DBA is ongoing senior database ownership at a fraction of a full-time hire. Instead of parachuting in for a single project and leaving, I monitor your environment continuously, catch problems before they surface, and stay accountable for the health of the database over time. Project work — a migration, a tuning engagement, an HA build — can be scoped separately or folded into an ongoing tier.
Who will I actually be working with?
You work directly with me, Bill Ennis, not a rotating ticket queue or an offshore first-line team. I have 30+ years of hands-on database engineering across SQL Server, Oracle, PostgreSQL, and MySQL. For projects that need extra bench strength, I bring in a vetted network of senior specialists — but I remain your point of contact and stay accountable for the work.
How quickly can you get started?
From assessment to active coverage is typically five business days. The sequence is a short self assessment, a 30-minute scoping call, a written scope of work with pricing and SLAs, and then monitoring deployed with alert thresholds tuned to your environment. Nothing is committed until you approve and sign the SOW.
Do you replace our internal team or work alongside it?
Most engagements are alongside. Many clients have capable developers or sysadmins who own the application but have no one who lives in the database layer. I fill that gap — handling monitoring, tuning, backups, and escalation — so your team can stay focused on shipping product rather than firefighting production incidents at 2am.
Are we locked into a long-term contract?
No multi-year lock-in. Engagements run month to month against an agreed scope of work, and you can adjust the tier as your environment grows or stabilizes. If your database load changes materially, we revisit the scope rather than leaving you paying for coverage you no longer need.
Cost and value
What this costs versus hiring in-house.
Pricing is quoted after a free assessment because no two database environments carry the same risk.
How much does remote DBA support cost?
Pricing is custom-quoted after a free assessment of your environment, because the honest answer depends on how many databases you run, which platforms they sit on, how critical they are, and what response time you need. There are three tiers — Essential, Professional, and Enterprise — and multi-database discounts are available. You get a fixed written price in the scope of work before anything starts.
Is a fractional DBA cheaper than hiring a full-time database administrator?
For most mid-sized companies, yes — substantially. A senior full-time DBA in the US carries a fully loaded cost well into six figures once salary, benefits, payroll tax, tooling, and recruiting are counted, and that single hire still cannot cover nights, weekends, and vacations alone. Fractional coverage gives you senior-level expertise across every major platform for a predictable monthly fee, with 24/7 monitoring included rather than bolted on.
How do I justify this to my CFO or leadership?
Frame it as avoided downtime, not added headcount. Use the downtime calculator to put a dollar figure on one hour of your database being unavailable, then compare that number to a month of coverage. For most businesses running order processing, billing, or customer-facing systems, a single prevented outage pays for the year.
What is not included in a support tier?
Ongoing tiers cover monitoring, incident response, health checks, backup verification, and — from Professional up — performance tuning and query optimization. Large discrete projects such as a full cloud migration, a new HA architecture build, or custom ETL development are scoped and quoted separately so you are not paying a migration premium every month. Enterprise includes migration support as part of the engagement.
Response times and coverage
What happens when something breaks at 3am.
Every tier includes 24/7 monitoring and emergency incident response. What differs is how fast a human is on it.
What are your response time SLAs?
Essential carries a 4-hour response SLA, Professional a 2-hour SLA, and Enterprise a 30-minute SLA with 24/7 priority phone support. All three tiers include round-the-clock automated monitoring and alerting, so detection is immediate regardless of tier — the SLA governs how quickly a human is engaged on the response.
Is monitoring really 24/7, including weekends and holidays?
Yes. Monitoring, alert thresholds, and automated checks run continuously — outages do not respect business hours, and neither does the alerting. The most common issues we catch overnight are runaway transaction log growth, disk exhaustion, failed backup jobs, and blocking chains that would have become a full outage by morning.
What counts as an emergency?
Anything that has taken the database down or is actively about to: the instance is unavailable, the application cannot connect, storage is about to fill, replication or the availability group has broken, corruption has been detected, or a restore is required. Those trigger immediate incident response. Non-urgent work — index recommendations, capacity planning, schema review — is handled during regular review cycles.
How do alerts and escalation actually reach you?
Alerts route from your monitoring into a paging path with defined escalation, so an unacknowledged critical alert keeps escalating rather than dying in an inbox. Professional and Enterprise clients also get Slack or Teams integration so your team sees the same signal and the same running commentary during an incident, plus phone escalation at the Enterprise tier.
Migration risk
Moving a production database without losing data.
On-premises to AWS, Azure, or GCP — planned, rehearsed, and reversible.
How much downtime should we expect during a cloud migration?
For most workloads the cutover window is measured in minutes, not hours, because the bulk of the data moves ahead of time through backup restore plus log shipping or logical replication, and the final switch is only the last delta. Very large or heavily transactional systems may need a longer window, and that number is established during planning — not discovered on cutover night.
How do you guarantee we do not lose data?
Migrations run against a rehearsed runbook with row counts, checksums, and application-level validation compared on both sides before the old system is retired. The source stays intact and available until validation passes, which means the rollback plan is real rather than theoretical. No cutover happens without a tested restore of the source.
What if the migration goes wrong mid-cutover?
Every migration plan includes a documented rollback with a defined abort point — a time by which, if validation has not passed, we revert to the source system and reschedule. Because the source remains untouched and consistent until the final switch, reverting is a DNS and connection-string change rather than a restore-from-backup scramble.
Which cloud platforms and targets do you migrate to?
AWS RDS and Aurora, Azure SQL Database and Managed Instance, GCP Cloud SQL, and managed Postgres services such as Neon, as well as self-managed instances on EC2 or VMs where a managed service is not a good fit. Part of the planning work is deciding which of those is actually right for your workload — the cheapest-looking option is frequently not the cheapest to run.
Security and compliance
Access, auditability, and regulated data.
How access is granted, what gets logged, and how backups are proven to work.
What level of access do you need to our systems?
Least privilege, granted through your own access process. That normally means a named account with the specific rights the work requires, connecting over your VPN or an approved bastion, with MFA where you have it. I do not need or want standing access to application data, and access can be time-boxed for project work and revoked by you at any point.
Is the work auditable?
Yes. Changes go through a documented change record with what was changed, when, why, and how to reverse it, and database-level auditing can be enabled so your compliance team sees privileged activity in your own logs rather than taking my word for it. Monthly reporting summarizes health, incidents, and changes.
Can you work with regulated data — HIPAA, PCI, SOX, GDPR?
Yes, and the practical approach is to avoid touching regulated data at all wherever possible: tuning, indexing, backup verification, and HA work almost never require reading customer records. Where a task genuinely requires production data, we work inside your controls — your environment, your access approvals, your logging — and can sign a BAA or equivalent agreement as required.
How do you verify our backups will actually restore?
By restoring them. Backup jobs reporting success prove very little; the only real evidence is a periodic test restore to a separate target with integrity checks run against the result, plus a measured restore duration so your RTO is a known number rather than a hope. Backup verification is included in every tier.
What is your disaster recovery approach?
Replication, failover, and backup strategy designed against a stated RPO and RTO, then tested and documented before you need it. That includes failover rehearsals, documented runbooks your team can execute without me, and periodic review as the environment changes. An untested DR plan is a document, not a recovery capability.
Platforms and tooling
The databases we actually cover.
Legacy on-premises installations through cloud-native managed services.
Which database platforms and versions do you support?
SQL Server 2012 through 2025 including Always On availability groups and replication; Oracle 11g through 23ai including RAC, Data Guard, and Exadata; PostgreSQL 10 and later including streaming and logical replication, Citus, and TimescaleDB; and MySQL 5.7+ and MariaDB 10.x including InnoDB tuning and replication topologies. Cloud managed services on AWS, Azure, and GCP are covered as well.
Do you handle database design and data modeling, or only operations?
Both. Schema design, normalization, indexing strategy, custom development, ETL, and workflow automation are all in scope — designing for performance up front is far cheaper than retrofitting it after the application is live. Architecture consulting is included at the Enterprise tier and available as project work otherwise.
Do we need to buy monitoring tools?
No. Monitoring is deployed as part of onboarding and alert thresholds are tuned to your workload rather than left at vendor defaults, which is the usual reason teams start ignoring alerts. If you already have tooling you like, we work with it instead of replacing it.
Can you tell us how healthy our database is before we commit to anything?
Yes, and there are two free ways to find out. The self assessment is a short questionnaire that scores your risk areas and coverage gaps, and the sp_Blitz report generator turns a SQL Server sp_Blitz CSV export into a prioritized findings report you can read on the page before deciding anything.
Still deciding
Not seeing your question?
Bring it to a 30-minute working session. No pitch deck — we look at your environment and I tell you what I'd do about it.