Amazon RDS Explained: Managed Relational Databases, Engines, Backups, and Scaling

Amazon RDS is AWS's managed relational database service for teams that want PostgreSQL, MySQL, MariaDB, Oracle, SQL Server, Db2, or Aurora without running the database operating system themselves. You still design schemas, tune queries, plan indexes, and set recovery objectives. AWS handles most of the provisioning, patching, backups, monitoring integration, and storage management that usually eats into engineering time.

That trade matters. RDS is not magic, and it will not fix a bad data model. But for most production applications, it removes enough operational work that your team can spend more time on reliability and performance instead of babysitting database servers.

What Amazon RDS Actually Manages

AWS positions Amazon RDS as an easy-to-manage relational database service tuned for total cost of ownership. In practical terms, RDS handles the parts that are necessary but rarely unique to your business:

• Database instance provisioning and configuration
• Automated backups and point-in-time recovery
• Minor version patching, based on your maintenance settings
• Storage allocation, storage autoscaling, and volume options
• Multi-AZ high availability for supported engines
• Integration with AWS Identity and Access Management, CloudWatch, KMS, and VPC networking

You still own the application-level decisions. Pick indexes carefully. Test migrations. Watch connection counts. I have seen a small PostgreSQL instance fall over because a Lambda function opened fresh connections on every invocation, and PostgreSQL returned FATAL: remaining connection slots are reserved for non-replication superuser connections. RDS was healthy. The application pattern was not.

Amazon RDS Engines: What You Can Run

Amazon RDS supports a broad engine set, which is one reason it works for both new cloud-native projects and older enterprise systems. The core engines include PostgreSQL, MySQL, MariaDB, Oracle, SQL Server, and Db2, with Amazon Aurora available in MySQL-compatible and PostgreSQL-compatible editions.

Amazon Aurora

Aurora is AWS's cloud-native relational database family. It stays compatible with MySQL or PostgreSQL at the application layer, but it uses AWS-designed distributed storage underneath. A few Aurora developments are worth watching:

• Aurora Serverless v2 scales capacity in small increments and can now scale to zero after inactivity once connections close.
• Aurora PostgreSQL Limitless Database is built for automated horizontal scaling of PostgreSQL-compatible workloads.
• Aurora DSQL is a PostgreSQL-compatible serverless distributed SQL database built for active-active high availability and multi-region strong consistency.
• pgvector support in Aurora PostgreSQL lets you store vector embeddings and run similarity search inside SQL workflows.
• The Aurora Data API supports HTTP-based database access for Aurora Serverless v2 and provisioned Aurora clusters, which helps stateless services and event-driven applications.

My view: choose Aurora when you need AWS-native scaling, read performance, or serverless behavior. If you need strict compatibility with a self-managed PostgreSQL extension stack, standard RDS for PostgreSQL may be the safer call.

PostgreSQL, MySQL, and MariaDB

RDS for PostgreSQL is a strong default for teams that need relational integrity, JSON support, extensions, and mature tooling. AWS has added features such as PL/Rust support for PostgreSQL 13 and 14, while Aurora PostgreSQL extends the AI use case with pgvector.

RDS for MySQL supports MySQL Community Edition 8.0 and 8.4, with MySQL 5.7 available through RDS Extended Support for customers who need more time to migrate. Do not treat Extended Support as a long-term plan. Use it as a bridge, then upgrade.

MariaDB remains a core open source engine on RDS. It is a good fit when your stack already depends on MariaDB-specific behavior.

Oracle, SQL Server, and Db2

RDS also carries a lot of commercial database workloads. RDS for SQL Server supports recent cumulative update and security release packages, including SQL Server 2022 CU22 and earlier supported branches. AWS documentation references GDR updates that address vulnerabilities such as CVE-2025-59499.

SQL Server Developer Edition on RDS is handy for non-production environments because it provides Enterprise features without SQL Server licensing costs for development and testing. For production sizing, the newer M7i and R7i instance classes can cut costs compared with older generations, and AWS reports up to 55 percent lower costs for certain RDS for SQL Server configurations when licensing is billed separately.

RDS for Oracle has added managed Oracle Data Guard switchover, automated backups for replicas, EFS integration for migration, and multitenant support through RDS Custom. RDS for Db2 brought IBM Db2 Standard and Advanced Edition into the RDS engine family, including hourly license subscription options through AWS Marketplace.

Backups, Snapshots, and Recovery

Backup features are one of the main reasons teams adopt RDS. Automated backups allow point-in-time recovery within your configured retention window. Manual snapshots let you keep a database image for longer-term retention, migration, or pre-change safety checks.

Use both. Automated backups are for operational recovery. Manual snapshots are for deliberate checkpoints, such as before a major schema migration or an application release.

Cross-region protection

AWS supports encrypted cross-region automated backups for certain engines and versions, including RDS for Oracle 12.1 and higher and RDS for PostgreSQL 9.06 and higher. Common supported region pairs include us-east-1 to us-west-2, eu-central-1 to eu-west-1, and ap-northeast-1 to ap-northeast-3.

For disaster recovery, do not stop at turning backups on. Test restore time. Check DNS cutover. Confirm parameter groups and security groups. A backup that has never been restored is only a hope with a timestamp.

Snapshot storage changes

AWS has stated that starting July 1, 2026, restoring an RDS snapshot to magnetic storage will no longer be possible. If you still run automation that assumes magnetic storage, update it now. The better choices for most workloads are gp3, io1, or io2 Block Express, depending on latency and throughput requirements.

Scaling Amazon RDS

Scaling RDS is not one thing. You can scale compute, memory, storage, connections, read capacity, or the database architecture itself. Find the bottleneck before you resize anything.

Vertical scaling

The simplest path is changing the DB instance class. Move from a smaller general-purpose instance to a larger memory-optimized or compute-optimized class when CPU, memory, or connection pressure becomes clear. This usually requires a maintenance event or failover, so plan it.

For SQL Server and Oracle, vertical scaling often runs into licensing. Bigger is not always better if the license bill doubles and the query plan was the real problem.

Storage scaling

RDS storage autoscaling can grow allocated storage as your database expands. It does not shrink storage. That catches beginners. If you over-allocate by accident or a batch job bloats the database, you may keep paying for that capacity until you migrate or rebuild.

RDS for Oracle and SQL Server now support up to 256 TiB of storage per database instance across multiple volumes. For high-throughput OLTP workloads, io2 Block Express is the serious option because it targets low latency and high I/O performance across RDS engines.

Serverless and distributed scaling

Aurora Serverless v2 fits spiky workloads, development systems, and applications where idle cost matters. Scaling to zero is especially useful for test environments, but only if your application tolerates cold starts and closed connections.

For large PostgreSQL-compatible workloads, Aurora Limitless Database points toward automatic horizontal scaling without manual sharding. Aurora DSQL goes further by targeting global transactional applications that need active-active multi-region writes with strong consistency. That is overkill for a regional CRUD app. It earns its keep in SaaS, financial, gaming, or collaboration systems where users write from multiple regions and consistency matters.

Monitoring: Performance Insights Is Changing

RDS monitoring has historically relied on Amazon CloudWatch plus Performance Insights. AWS documentation states that Performance Insights reaches end of life on November 30, 2025. After that date, the Performance Insights console, flexible retention settings, and related pricing will no longer be available.

AWS recommends moving DB instances to Database Insights before that deadline. If you run production RDS today, put this on your 2025 platform roadmap. Waiting until the last quarter is how monitoring migrations turn into outage work.

AI, Search, and Analytics Integrations

RDS is no longer only a transaction store. AWS has made it easier to connect relational data with search and AI workflows.

• OpenSearch Ingestion integration can stream changes from RDS and Aurora into Amazon OpenSearch Service for search, analytics, and observability use cases.
• pgvector on Aurora PostgreSQL lets you store embeddings and run similarity search close to relational data.
• The Aurora Data API helps stateless applications call the database without maintaining long-lived TCP connections.

Keep expectations realistic. pgvector is excellent for moderate-scale semantic search where relational filtering matters. If you need billion-vector retrieval with specialized indexing and strict latency targets, compare it against dedicated vector search systems before committing.

When Amazon RDS Is the Right Choice

Use Amazon RDS when you want managed operations but still need a real relational database. Good fits include:

• Web and mobile application backends
• Enterprise systems running Oracle, SQL Server, or Db2
• PostgreSQL or MySQL workloads that need backups, patching, and Multi-AZ options
• Development and test environments that should match production engines
• AI search applications using Aurora PostgreSQL and pgvector
• Operational data pipelines that feed OpenSearch

RDS is the wrong fit when you need operating system access, custom kernel tuning, unusual extensions not supported by RDS, or full control over database binaries. In those cases, consider RDS Custom where supported, Amazon EC2 self-management, or a purpose-built database service.

Skills to Build Next

If you are preparing for cloud architecture, DevOps, data engineering, or database administration work, learn RDS by building a small production-style stack. Create a private RDS PostgreSQL instance, attach an application, enable automated backups, test a restore, add CloudWatch alarms, and break the connection pool on purpose. You will learn more from that one lab than from reading parameter lists.

For a structured path, pair this topic with Global Tech Council learning resources in AWS, cloud computing, cybersecurity, data science, and AI engineering. Start with RDS fundamentals, then add VPC networking, IAM, KMS encryption, backup strategy, and database performance tuning. Your next practical task: deploy RDS PostgreSQL or Aurora in a private subnet and document your recovery time from a snapshot restore.