Amazon RDS support from MinervaDB gives you the database engineering that AWS does not include with the service: 24×7 incident response with a 15-minute S1 target, query and index tuning, parameter-group engineering, replication and Multi-AZ design, cost right-sizing, major-version upgrades before Extended Support fees start, and migration planning into or out of RDS and Aurora. We cover every RDS engine, with the deepest bench on RDS for PostgreSQL, RDS for MySQL, RDS for MariaDB, Aurora PostgreSQL and Aurora MySQL, and working practices for RDS for SQL Server, RDS for Oracle and RDS for Db2.
What AWS Manages, and What Is Still Your Problem
RDS takes the operating system, storage provisioning, patching, automated backups and Multi-AZ failover mechanics off your plate. It does not take the database off your plate. Slow queries, missing or bloated indexes, lock contention, connection storms, replication lag on read replicas, parameter groups left at defaults, transaction ID wraparound on PostgreSQL, InnoDB configuration on MySQL, storage IOPS starvation, instances sized by guesswork, and the version calendar are all still yours. AWS Support will confirm the service is healthy; it will not tell you why your checkout query takes four seconds. That gap is what MinervaDB’s RDS support fills.
Engine coverage and managed features follow the Amazon RDS User Guide; we re-verify the RDS deprecation calendar for every engine at the start of each engagement.
Amazon RDS Support Services
24×7 incident response
Named engineers on a round-the-clock rota. Typical S1 calls: a primary that failed over and applications that did not reconnect, a read replica hours behind, storage full, a runaway query pinning the CPU, a Multi-AZ failover during a deployment window, or a restore that has to happen now. We work on your shared channel until the incident closes and deliver a written root-cause analysis with the evidence and the prevention steps.
Performance engineering across the RDS engines
We use Performance Insights and Enhanced Monitoring as the starting point and go from there into the engine: pg_stat_statements, EXPLAIN (ANALYZE, BUFFERS), autovacuum and bloat analysis on RDS for PostgreSQL and Aurora PostgreSQL; the slow query log, performance_schema, EXPLAIN ANALYZE and InnoDB status on RDS for MySQL, RDS for MariaDB and Aurora MySQL; Query Store, wait statistics and index usage DMVs on RDS for SQL Server; AWR-equivalent Performance Insights data on RDS for Oracle. Parameter-group changes are proposed as current value, proposed value, unit and whether the change is dynamic or requires a reboot, and applied with a rollback plan.
High availability, replicas and failover
Multi-AZ instance deployments versus Multi-AZ DB clusters (writer plus two readers across three zones, with reader traffic served), read-replica topologies including cross-region replicas, Aurora Global Database, RDS Proxy for connection pooling and faster failover, application-side retry and DNS TTL behaviour, and rehearsed failover drills so the recovery time is measured rather than assumed. Blue/Green Deployments are used for major upgrades and risky parameter changes where the engine supports them.
Backups, point-in-time recovery and DR
Automated backup retention and PITR windows set from the actual recovery objectives, cross-region and cross-account snapshot copies, AWS Backup policies where they fit, encrypted snapshot handling with KMS, and scheduled restore drills into a scratch instance with the measured RTO recorded in the runbook. For engines where logical backups still matter (PostgreSQL logical dumps for schema portability, MySQL binary log retention for external tooling) we manage those too.
Version lifecycle and Extended Support
RDS Extended Support bills a per-vCPU-hour surcharge once an engine major version passes its community end of life, and the surcharge increases over time. We track the RDS deprecation calendar for every instance in your account, plan major-version upgrades with a compatibility check, a Blue/Green or replica-based rehearsal and a rollback, and execute them inside your maintenance windows. Estates paying Extended Support without a plan to leave it are flagged as an S2 finding in every health check.
Cost right-sizing and FinOps
Instance classes and Graviton migrations chosen from measured CPU, memory and I/O, storage type and IOPS (gp3 versus io2, provisioned IOPS that are never used), Aurora I/O-Optimized versus Standard from actual I/O spend, reserved-instance coverage, idle and oversized replicas, and snapshot retention sprawl. We report the savings as estimates until they appear on the bill.
Security and compliance
IAM database authentication, KMS encryption, TLS enforcement, parameter-level hardening, audit logging (pgAudit, MySQL and MariaDB audit plugins, SQL Server Audit), Secrets Manager rotation, VPC and security-group design, and the evidence for SOC 2, HIPAA, PCI DSS, GDPR and India’s DPDP Act.
Migrations into and out of RDS
Into RDS or Aurora from self-managed PostgreSQL, MySQL, MariaDB, SQL Server and Oracle, and between RDS engines (Oracle or SQL Server to Aurora PostgreSQL is the most common), using AWS DMS, native logical replication, Schema Conversion Tool and hand-built pipelines as the case requires. Out of RDS to self-managed PostgreSQL or MySQL on EC2 or Kubernetes when cost, control or extension needs make that the better answer. We say which, in writing, before the project starts.
Engine-by-Engine Coverage on RDS and Aurora
| Engine | What we watch | Where RDS estates usually go wrong |
|---|---|---|
| RDS for PostgreSQL, Aurora PostgreSQL | pg_stat_statements, autovacuum activity, age(datfrozenxid), replication lag, wait events in Performance Insights, Aurora storage I/O |
Autovacuum left at defaults on large tables; wraparound risk; missing indexes hidden by oversized instances; logical replication slots filling storage |
| RDS for MySQL, RDS for MariaDB, Aurora MySQL | Slow query log, performance_schema, InnoDB buffer pool and redo metrics, replica lag, binary log retention |
Parameter groups at defaults; innodb_buffer_pool_size not matching the instance class; long-running transactions holding history; replicas sized smaller than the primary |
| RDS for SQL Server | Query Store, wait statistics, index usage and fragmentation DMVs, tempdb pressure, Always On (Multi-AZ) health | Missing index maintenance; parameter sniffing; licence-included instance classes chosen without workload evidence |
| RDS for Oracle | Performance Insights, ASH-equivalent data, option groups, RMAN-equivalent snapshot and PITR behaviour | Licensing model chosen without a licence position review; upgrade paths blocked by option-group settings |
| RDS for Db2 | MON_GET_* monitoring views, bufferpool hit ratios, runstats and reorg state |
Statistics never refreshed after migration from on-premises; bufferpools sized for the old hardware |
The First 30 Days of an RDS Support Engagement
Days 1 to 5: takeover assessment
Cross-account role and credentials issued, every RDS and Aurora instance inventoried with engine version, instance class, storage configuration, Multi-AZ and replica topology, parameter-group deltas from default, backup retention, Extended Support exposure and monitoring coverage. Performance Insights and engine-level statistics are collected for a baseline. Output: a written assessment ranked by risk, with the evidence for each item.
Days 6 to 15: stabilise
The S1 and S2 findings are fixed first: backup retention and PITR windows corrected, alerting wired to our on-call rotation and yours, parameter groups corrected where defaults are wrong for the instance, replication lag causes removed, storage and IOPS headroom restored. Each change follows the current-value, proposed-value, reload-or-reboot format with a rollback.
Days 16 to 30: runbook and drills
The runbook for your estate is written and reviewed with your team: failover procedures, restore procedures, escalation paths, maintenance calendar, upgrade plan for any version approaching Extended Support. The first restore drill runs on a scratch instance and the measured recovery time is recorded. From day 31 the engagement is in steady state: 24×7 coverage, monthly health reports with the measured metrics behind every recommendation, quarterly failover and restore drills, and advisory hours for what your team is planning next.
RDS Cost: Where the Savings Actually Are
RDS bills are dominated by instance hours, storage and IOPS, and by Extended Support once a version ages out.
The savings we find most often are instances sized for a workload that no longer exists or that a query fix would halve; provisioned IOPS on gp2 or io1 volumes that gp3 covers at a fraction of the price; Aurora Standard billing on I/O-heavy workloads that I/O-Optimized would cap; read replicas kept for a reporting job that moved to a warehouse a year ago; and snapshot retention that nobody reviewed.
Reserved-instance coverage is modelled last, after the right-sizing, so you do not commit to the wrong instance class for a year. Every saving is reported as an estimate until it appears on the invoice, and none is taken at the expense of a recovery objective.
Service Levels
| Severity | Definition | Response target |
|---|---|---|
| S1 | Production down, failover in progress, data at risk | 15 minutes, 24×7 |
| S2 | Severe degradation, replica lag affecting users, no workaround | 12 hours |
| S3 | Degradation with a workaround | 24 hours |
| S4 | Questions, planning, advisory | 48 hours |
Pricing
24×7 RDS support and remote DBA retainers start at US $4,500 per quarter, with named engineers, an onboarding assessment of every RDS and Aurora instance in scope, a runbook, monitoring integration with CloudWatch, Performance Insights, Prometheus or Datadog, a monthly health report, quarterly restore and failover drills, and advisory hours that roll into project work if unused. Remote consulting is US $300 per hour and on-site consulting US $500 per hour plus travel; health checks and migrations are quoted on a fixed scope.
Test every change on a restored snapshot or a Blue/Green staging environment first, keep manual snapshots before parameter and version changes, and maintain a robust disaster-recovery posture with cross-region copies.
Why MinervaDB for RDS
Our engineers come from the database engines, not from the console. The same team runs self-managed PostgreSQL, MySQL, MariaDB, SQL Server, Oracle and Db2 estates, which is why we can see past the RDS abstraction to the query plan, the vacuum backlog or the InnoDB redo pressure underneath. RDS support is part of our AWS data platform engineering practice alongside Aurora, DynamoDB, ElastiCache and Redshift, and we remain vendor-neutral: when a workload should leave RDS, or should never have been on it, we say so.
Frequently Asked Questions
Which Amazon RDS engines do you support?
RDS for PostgreSQL, MySQL, MariaDB, SQL Server, Oracle and Db2, plus Aurora PostgreSQL and Aurora MySQL, including Aurora Serverless v2 and Aurora Global Database.
How is this different from AWS Support?
AWS Support covers the platform and the service’s own health. We cover the database: performance, schema and index design, replication and failover procedures, upgrades, cost and incident response with root-cause analysis. Most customers hold both.
Can you help us get off RDS Extended Support charges?
Yes. We inventory the affected instances, plan and rehearse the major-version upgrades, and execute them in your maintenance windows with a rollback path.
Do you need access to our AWS account?
We work through a cross-account IAM role scoped to the RDS, CloudWatch and Performance Insights permissions the work needs, plus database credentials issued from your Secrets Manager. Every action is visible in your CloudTrail.
Do you support Aurora as well as RDS?
Yes. Aurora PostgreSQL and Aurora MySQL, including Global Database, Serverless v2, I/O-Optimized decisions and zero-ETL integrations into Redshift, are covered by the same team.
Can you take over from an outgoing DBA or a previous provider?
Yes. Onboarding starts with a takeover assessment that documents topology, parameter groups, backup state and monitoring gaps and produces the runbook we then operate from. Nothing changes until you have reviewed it.
How do we start?
Book a scoping call. For an active production incident, the same page reaches the 24×7 team.