---
title: Amazon Aurora
description: AWS-built cloud-native relational database compatible with MySQL and PostgreSQL, delivering up to 5x MySQL and 3x PostgreSQL performance at lower cost.
url: https://www.factualminds.com/glossary/amazon-aurora/
publishDate: 2026-06-13
updateDate: 2026-06-13
---

# Amazon Aurora

> AWS-built cloud-native relational database compatible with MySQL and PostgreSQL, delivering up to 5x MySQL and 3x PostgreSQL performance at lower cost.

## Definition

Amazon **Aurora** is AWS's cloud-native relational engine, compatible with **MySQL** and **PostgreSQL** wire protocols. Storage is distributed across **six copies in three AZs** with quorum writes; compute (DB instances) attaches to shared storage volumes that **auto-scale from 10 GB to 128 TB** without pre-provisioning. Aurora delivers higher throughput than standard RDS on the same instance classes, **up to 15 low-latency read replicas**, and failover often under **30 seconds** because replicas attach to the same storage substrate.

**Aurora Serverless v2** scales ACUs (Aurora Capacity Units) in fine increments with per-second billing — ideal for variable or multi-tenant SaaS loads. **Aurora Global Database** replicates to secondary regions with typical sub-second lag for global read scaling and cross-region DR. Aurora integrates with **Bedrock and SageMaker** via SQL functions for in-database inference on rows without exporting data.

| Aspect        | Standard RDS    | Aurora                         |
| ------------- | --------------- | ------------------------------ |
| Storage       | EBS, pre-sized  | Auto-scaling, 6-way replicated |
| Failover      | 60–120s typical | Often under 30s                |
| Read replicas | Up to 5         | Up to 15                       |
| Serverless    | N/A             | Serverless v2                  |

## When to use it

- High-throughput OLTP where standard RDS CPU or IOPS ceilings show up in Performance Insights first.
- Applications needing **fast failover**, many read replicas, or **Global Database** for international users.
- Variable workloads (dev/test, SaaS tenants) that benefit from **Serverless v2** scaling without over-provisioned instances.
- Teams already on MySQL/PostgreSQL who can accept minor compatibility testing for Aurora-specific behaviors.

## When not to use it

- Tiny dev databases where **`db.t4g.micro` RDS** is cheaper — Aurora has a higher floor cost.
- Heavy **analytics scanning** — offload to Redshift zero-ETL, Aurora parallel query helps OLTP-ish reports but not warehouse SLAs.
- Global **active-active writes across regions** — Aurora Global Database has a single write region; see **Aurora DSQL** for multi-region OLTP.

## Tips

- Mix **provisioned writer + Serverless v2 readers** in the same cluster for cost-efficient read scaling on bursty reporting queries.
- Use **Aurora I/O-Optimized** when I/O charges exceed ~25% of Aurora spend — math depends on workload; AWS provides calculator inputs in console.
- Enable **Backtrack** (MySQL-compatible) only when you understand storage implications — not a free undo button.
- Call ML via **`aws_bedrock_invoke_model()`** for row-local enrichment, but cap concurrency — inference from SQL can starve OLTP connections.
- Run a **compatibility suite** (ORM migrations, locking tests, replication slots) before cutover — Aurora is compatible, not identical.

## Gotchas

- **Serious:** Assuming **drop-in compatibility** without tests — replication slots, `pg_logical`, and some MySQL isolation nuances differ and break cutover weekends.
- **Serious:** **Serverless v0 confusion** — Serverless v2 is fundamentally different (instant scale, shared cluster); do not port v1 assumptions.
- **Regular:** **Reader endpoint load balancing** is connection-level, not query-aware — long-running reports on readers can skew load unless you pin endpoints.
- **Regular:** **Global Database failover** is manual or scripted — sub-minute RTO requires runbooks, not just checkbox enablement.
- **Regular:** Aurora **storage grows automatically** but deleted data compacts slowly — watch `VolumeBytesUsed` vs logical database size during churn-heavy migrations.

## Official references

- [Aurora Global Database](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database.html) — RPO/RTO and failover mechanics.
- [Aurora PostgreSQL differences](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Replication.html) — compatibility notes vs community PostgreSQL.

## Related FactualMinds content

- [Amazon RDS](/glossary/amazon-rds/) — managed relational baseline
- [Aurora DSQL](/glossary/aurora-dsql/) — multi-region distributed SQL
- [AWS RDS Consulting](/services/aws-rds-consulting/)
- [AWS Data Analytics](/services/aws-data-analytics/)
- [Cloud Compliance Services](/services/cloud-compliance-services/)

## Related AWS Services

- aws-rds-consulting
- aws-data-analytics
- cloud-compliance-services

## Related Posts

- aws-well-architected-framework-6-pillars-explained

---

*Source: https://www.factualminds.com/glossary/amazon-aurora/*