India’s Leading Domain & Web Hosting Provider
Support
Domain & Login
Blog
Managed Database Operations: Remote DBA for RDS, Azure SQL, Cloud SQL
Managed database operations is the ongoing DBA work on cloud databases that providers do not do for you: query and index tuning, version upgrade planning, failover and restore drills, parameter changes, access reviews and capacity planning. NTSPL's DBAs run this for Amazon RDS and Aurora, Azure SQL and PostgreSQL, Cloud SQL and AlloyDB, for teams without a full-time DBA.
Delivered on
In scope
DBA Duties That Managed Databases Still Need
Managed database services patch the host and take backups, so many teams assume the DBA job has gone away. It has not. Query plans regress after a statistics update. A table grows to 400 GB without a partitioning plan. A major version reaches end of standard support and RDS Extended Support or Cloud SQL extended support charges start appearing on the bill. Multi-AZ failover is configured but has never been tested with the application's connection handling. These are the causes of most database incidents we are called into.
NTSPL's DBAs take a defined set of recurring duties. Every week we review the top queries by total time and open tuning tickets with the exact index or rewrite. Every month we check growth, connection peaks, replication lag and parameter drift. Every quarter we run a failover drill and a point-in-time restore. Major version upgrades are planned six months ahead and executed with blue-green or replica-based cutovers measured in minutes.
Database Symptoms That Call for a Remote DBA
Signals you need Managed Database Operations
- Database CPU or IOPS regularly exceeds 80% at peak and the only response so far has been a larger instance
- A major engine version is within 12 months of end of standard support, or extended support charges have already started
- Nobody has tested a Multi-AZ or zone-redundant failover with the real application in the last year
- Slow queries surface as customer complaints before anyone on the team sees them
- Your only database expertise sits with one developer who is also shipping features
When to choose something else
- You want to change engines, such as Oracle to PostgreSQL; that is a database modernization project with code refactoring
- Your databases are still on-premises and need migrating first; a database migration engagement comes before operations
Weekly, Monthly and Quarterly DBA Work We Own
Query and index tuning
Weekly top-query review by total time, with specific index, rewrite or plan-forcing recommendations ticketed to developers.
Version lifecycle
Tracking minor and major versions against provider support dates; upgrades rehearsed on clones and cut over with blue-green or replicas.
Resilience drills
Quarterly failover tests and point-in-time restores, timed and checked against the application's reconnection behaviour.
Capacity and parameters
Monthly growth, connection, IOPS and lag trends; parameter group drift checked against an approved baseline.
Access and audit
Quarterly review of database users and roles, removal of shared accounts and audit logging for privileged actions.
Database Operations Cadence from Query Review to Upgrade
Remote DBA Cadence: Query Review, Drills and Blue-Green Upgrades
Performance telemetry from each managed database drives weekly tuning tickets and monthly capacity reviews. Quarterly drills test failover and restore, while version upgrades run through a rehearsed clone and a blue-green or replica cutover.
Select any component
Remote DBA Cadence: Query Review, Drills and Blue-Green Upgrades: click any of its 8 components to see its role and the design choice NTSPL makes for it, or trace the 7-step primary path.
Managed Database Engines We Operate
We use RDS Blue/Green Deployments for major version upgrades on MySQL, MariaDB and PostgreSQL, rehearsing on a clone first, and RDS Proxy to shorten application reconnection during failover.
On Azure SQL, Query Store history lets us spot plan regressions after a deployment and force a known-good plan while the developers fix the query.
Database Center gives a fleet view of Cloud SQL and AlloyDB health and version issues, and maintenance deny periods keep provider updates away from business peaks.
Tuning, Upgrade and Failover Choices
Scale up or tune
Before increasing instance size, check whether the top five statements account for more than half of database time. If they do, tuning usually returns more than doubling the instance, at no recurring cost. Scale up when load is spread across many queries, when memory pressure forces disk reads for the working set, or when tuning would take longer than the business can wait.
Major version upgrade approach
Use blue-green or logical replication cutovers for production where available, keeping downtime to a few minutes, and in-place upgrades only for non-production or small databases with an accepted window. Rehearse on a snapshot clone, compare plans for the top 20 queries, and keep the old environment for 48 hours. Plan to finish six months before end of standard support.
Failover readiness
Multi-AZ or zone-redundant setups protect against infrastructure failure only if applications reconnect. Test quarterly with a forced failover and measure total impact, not just database switch time. Use connection proxies such as RDS Proxy or PgBouncer, DNS TTLs under 30 seconds and retry logic. Target total application impact under 60 seconds for tier-1 databases.
Who changes the schema
Developers own schema changes through migrations in their pipeline; DBAs review migrations on tables over 10 GB or with high write rates, because locking ALTERs can stall production. We recommend online schema change tools or expand-and-contract patterns for large tables, and we schedule those changes in low-traffic windows. Rollback scripts are mandatory.
Taking Over Day-Two Database Operations
Database estate review
Inventory engines, versions, sizes, HA settings, parameters and backup configuration; capture top queries.
Quick fixes
Address the highest-impact queries, missing alarms and risky parameters.
Drill and lifecycle plan
Run the first failover and restore drill and publish a version upgrade calendar.
Steady-state cadence
Weekly query reviews, monthly capacity reports, quarterly drills and planned upgrades.
What you receive
Database Health Targets
| KPI | Typical target |
|---|---|
| Peak database CPU | Under 70% at business peak |
| Application impact during failover | Under 60 seconds for tier-1 |
| Instances on versions past standard support | Zero |
| Top-query p95 latency | Agreed per service, trend flat or improving |
Database Operations Hazards
| Risk | How NTSPL prevents it |
|---|---|
| A major version upgrade changes query plans and slows a critical report | Plan comparison for top queries on a rehearsal clone and plan forcing where supported. |
| Large table ALTER locks production during business hours | DBA review of migrations on large tables and online schema change tools. |
| Test clones of production expose personal data | Clones stay in the same Indian region with production-equivalent access, and are deleted after use. |
Do managed databases like RDS or Azure SQL still need a DBA?
Yes, though less of one. Providers handle host patching, backups, storage and the mechanics of high availability. They do not tune your queries, decide when and how to move to the next major version, check that your application survives a failover, review who has access, or plan for a table that will triple next year. Those tasks need perhaps a quarter to half of a DBA's time for a typical mid-size estate, which is why a shared remote DBA service fits better than a full-time hire. Large estates with dozens of busy databases may justify an in-house DBA plus our cover for nights and drills.
Key facts: Managed Database Operations
Managed Database Operations in Practice
2 Managed Database Operations scenarios, from Insurance web aggregator and Airline catering, plus related platform case studies.
Insurance aggregator cuts quote-engine database time 64% before motor renewal season
Airline caterer moves 14 Cloud SQL instances off MySQL 5.7 with 4-minute cutovers
NBFC moves loan-origination Oracle database to Aurora PostgreSQL and drops EE licences
Microfinance lender moves loan SQL Server to Managed Instance in an 18-minute cutover
Managed Database Operations: Frequently Asked Questions
What does a managed database operations service cost?
We price per database instance by tier. For a typical estate of 5-15 production instances across engines, expect ₹60,000 to ₹2.2 lakh a month, covering weekly reviews, monthly reports, quarterly drills and up to an agreed number of upgrade cutovers per year.
Will you handle engine upgrades end to end?
Yes. We plan the version path, rehearse on a clone with your test suite, compare query plans, schedule the cutover and run it with rollback ready. Your team confirms application behaviour before and after. Each upgrade has a written go or no-go checkpoint before the cutover begins.
What are extended support charges and how do we avoid them?
Amazon RDS and Google Cloud SQL charge extra to keep running some major versions after end of standard support. Upgrading before that date avoids the charge; we keep a version register so the upgrade starts six months ahead. Other engines and providers have their own end-of-support policies, which the register tracks too.
Do you need access to our data?
We need administrative access to databases but avoid reading business data. Access runs through just-in-time roles with session logging, and any task requiring data inspection is approved by ticket. This supports purpose limitation and access logging under the DPDP Act 2023.
Do you support self-managed databases on VMs?
Yes, for SQL Server, PostgreSQL, MySQL and MongoDB on VMs, with additional duties such as OS-level backup checks and engine patching. Oracle on VMs is supported for operations tasks, though licensing questions stay with you. Coverage includes replication checks and backup verification.
How do you work with our developers?
Through tickets that contain the statement, plan and suggested change, tested on a clone. We join sprint planning once a month to prioritise database work, and review migrations on large tables before release. Urgent fixes during incidents bypass the queue through the bridge.