Managed RDB
Last reviewed: August 2026
Overview
Section titled “Overview”Running a database on-premises requires you to handle server installation, OS patching, DB engine installation, backup configuration, replication setup, and failover entirely yourself. A managed RDB has the vendor take on this operational burden instead, letting you focus solely on data and queries.
The changing role of the DBA
Section titled “The changing role of the DBA”| Area | On-premises DBA | Managed RDB environment |
|---|---|---|
| OS/patch management | Performed directly | Handled by the vendor |
| Backup/recovery | Writing and testing scripts | Automatic backup + built-in PITR |
| HA/replication setup | Designed and operated directly | A multi-AZ checkbox |
| Performance tuning | Both queries and infrastructure | Focus on query/schema optimization |
| Capacity planning | Purchasing/expanding disks | Online expansion or auto-scaling |
Product comparison
Section titled “Product comparison”General-purpose managed RDB
Section titled “General-purpose managed RDB”| Vendor | Product | Type | Supported engines |
|---|---|---|---|
| AWS | RDS | Managed | MySQL, PostgreSQL, MariaDB, Oracle, SQL Server |
| AWS | Aurora | Native | MySQL/PostgreSQL compatible. In-house designed distributed storage |
| AWS | Aurora DSQL | Native | PostgreSQL-compatible distributed SQL. Serverless. Designed for 99.99% single-Region / 99.999% multi-Region availability. GA (May 2025). CDC support GA (Jul 2026) |
| Azure | Azure SQL Database | Managed | Based on SQL Server |
| Azure | Azure Database for MySQL/PostgreSQL | Managed | Managed open-source engines |
| Google Cloud | Cloud SQL | Managed | MySQL, PostgreSQL, SQL Server |
| Google Cloud | AlloyDB | Native | PostgreSQL compatible. In-house design. Built-in vector search. AlloyDB Omni (K8s Operator 1.7.0 GA) for on-premises/multicloud. PostgreSQL 18 compatible |
| OCI | Autonomous Database | Native | Based on Oracle DB. Automatic tuning/patching/scaling |
| OCI | MySQL HeatWave | Managed | MySQL compatible. Unified OLTP + OLAP processing |
What is a cloud-native DB
Section titled “What is a cloud-native DB”Standard managed offerings (RDS, Cloud SQL) use the existing DB engine as-is, with only operations automated. Cloud-native DBs such as Aurora and AlloyDB have a fundamentally different architecture, having designed the storage layer themselves.
| Item | Standard managed | Cloud-native |
|---|---|---|
| Storage | Block disk attached to the instance | Distributed storage decoupled from compute |
| Replication | Full data copy to a separate instance | The storage layer itself is multi-AZ replicated |
| Adding a read replica | Requires copying data (slow) | Shares the same storage (fast) |
| Failover | Switch to a standby instance (tens of seconds) | Attach new compute (seconds) |
| Capacity | Disk size pre-specified | Auto-scaling |
Globally distributed DB
Section titled “Globally distributed DB”A DB that distributes data worldwide across regions and allows reads/writes in each region. Unlike a standard managed offering’s “cross-region read replica,” some services support multi-region writes.
| Type | Vendor | Product | Multi-region writes | Consistency |
|---|---|---|---|---|
| RDB | AWS | Aurora Global Database | — (reads distributed only; writes single-region) | Strong consistency (primary) |
| RDB | AWS | Aurora DSQL | Supported (active-active multi-region) | Strong consistency (distributed transactions) |
| RDB | Google Cloud | Spanner | Supported | Strong consistency (global transactions) |
| NoSQL | Azure | Cosmos DB | Supported | 5 selectable consistency levels |
| NoSQL | AWS | DynamoDB Global Tables | Supported | Eventual consistency (across regions) |
| RDB | OCI | Autonomous Data Guard | — (cross-region replication) | Strong consistency (primary) |
Why global DBs are hard
Section titled “Why global DBs are hard”Synchronizing data across regions is constrained by physics (the speed of light). Intercontinental RTT can reach hundreds of milliseconds, so synchronously replicating every write drastically degrades performance.
| Trade-off | Description |
|---|---|
| Strong consistency + multi-region writes | Only Spanner supports this. Very high cost. Based on TrueTime (atomic clocks) |
| Eventual consistency + multi-region writes | DynamoDB Global Tables, Cosmos DB. Requires a conflict-resolution strategy |
| Strong consistency + single-region writes | Aurora Global DB. Only reads are distributed. Simplest but has write latency |
Key differences
Section titled “Key differences”AWS Aurora — MySQL/PostgreSQL compatible. Storage is automatically replicated as 6 copies across 3 AZs. Aurora Serverless can bring cost to zero while idle.
Azure SQL Database — Based on SQL Server. Provides the smoothest migration path for existing SQL Server workloads. Scales up to 100TB in the Hyperscale tier.
Google Cloud AlloyDB — PostgreSQL compatible. Built-in vector search is a strength for AI workload integration. AlloyDB Omni enables on-premises and multicloud (including GDC) deployments, with PostgreSQL 18 compatibility and Transparent Data Encryption (TDE) support.
OCI Autonomous Database — Based on Oracle DB. Automatic tuning, automatic patching, automatic scaling. MySQL HeatWave also supports unified OLTP+OLAP processing.
Database@Cloud
Section titled “Database@Cloud”Oracle is pursuing a strategy of placing its own database directly inside competitors’ data centers.
| Service | Location | Characteristics |
|---|---|---|
| Oracle Database@Azure | Azure DC | Native provisioning from the Azure Portal |
| Oracle Database@AWS | AWS DC | Direct provisioning from the AWS console. Rebranded as Oracle AI Database@AWS. Expanded to 22 regions (Aug 2026). Singapore and Milan added |
| Oracle Database@Google Cloud | Google Cloud DC | Used directly from the Google Cloud console |
With the app and DB in the same data center, this minimizes latency, eliminates egress cost, and satisfies data sovereignty requirements.
What to choose when
Section titled “What to choose when”| Situation | Recommendation |
|---|---|
| MySQL/PostgreSQL + high availability + automatic storage expansion | AWS Aurora |
| Migrating an existing SQL Server workload | Azure SQL Database |
| PostgreSQL + integrated AI/vector search | Google Cloud AlloyDB |
| Oracle DB + automatic tuning/patching | OCI Autonomous Database |
| Zero cost while idle (dev/test) | Aurora Serverless, Azure SQL Serverless |
| Unified OLTP + OLAP MySQL | OCI MySQL HeatWave |
Common mistakes
Section titled “Common mistakes”- Single-AZ deployment — Deploying a production DB in a single AZ means the service goes down completely if that AZ fails. Always enable multi-AZ.
- Not testing backups — Setting up automatic backups without actually testing recovery can mean recovery fails or takes longer than expected during an incident.
- Operating without indexes — Operating without proper indexes causes query performance to degrade sharply as data grows, and full table scans increase DB load.
Checklist
Section titled “Checklist”- Have you enabled multi-AZ (or another high-availability configuration)?
- Have you set up automatic backups and performed a recovery test?
- Have you enabled and are you monitoring the slow query log?
- Have you configured connection pooling (RDS Proxy, PgBouncer, etc.)?