This article is based on reporting originally published by The Register at the time of Aurora Serverless PostgreSQL’s general availability announcement.
Aurora Serverless Adds PostgreSQL Support
Amazon Web Services announced the general availability of PostgreSQL compatibility on its Aurora Serverless platform. For teams already using Aurora with MySQL and looking for a fully managed, auto-scaling PostgreSQL option, this represents a significant milestone. But before you migrate or spin up a new cluster, it pays to understand exactly what you are getting — and what you are paying for.
What Is Amazon Aurora?
Aurora is AWS’s managed relational database service built for cloud-scale workloads. Its architecture decouples compute from storage: the storage layer is always replicated across multiple Availability Zones (AZs) for durability, while the compute layer can be configured separately. Aurora also supports low-latency global reads through cross-region replicas.
AWS deliberately describes its Aurora offerings as MySQL-compatible and PostgreSQL-compatible rather than as MySQL or PostgreSQL. This is an important distinction — Aurora’s internal implementation differs from the upstream open-source databases, which can affect the behaviour of certain features, extensions, and edge-case queries.
Two Pricing Models: Provisioned vs. Serverless
Provisioned Aurora
The traditional Aurora model is instance-based. AWS recommends running a primary instance plus one or more read replicas. You pay for three components separately:
- Compute instances — pricing starts at approximately $0.088 per hour for a
db.t3.mediuminstance (the minimum supported for Aurora PostgreSQL at the time of this announcement). Adb.t3.mediumprovides 2 vCPUs, 4 GB RAM, and up to 5 Gbps network performance. - Storage — approximately $0.11 per GB per month.
- I/O requests — approximately $0.22 per million requests.
With provisioned Aurora, you have predictable costs and full control over instance sizing. It suits steady, predictable workloads well.
Aurora Serverless
Aurora Serverless removes the need to select or manage instances. Instead, capacity is expressed in Aurora Capacity Units (ACUs). Each ACU represents a combination of compute and memory, analogous to a database instance but abstracted away from you. You set a minimum and maximum ACU range, and Aurora scales automatically within those bounds.
Pricing for the serverless model at launch was approximately $0.06 per ACU per hour, with a recommended minimum of two ACUs. Storage and I/O are billed at the same rates as provisioned Aurora.
Because the ACU abstraction layers over raw instance types, the exact mapping of ACUs to vCPUs and RAM is not publicly documented in precise detail. This makes it harder to do a direct like-for-like cost comparison with provisioned instances.
Cost Trade-offs: When Does Serverless Make Sense?
Serverless Aurora is generally more expensive than provisioned Aurora for steady workloads. The value proposition is auto-scaling: when your database is idle or lightly loaded, it scales down, and you stop paying for idle compute. For workloads that are highly variable, bursty, or intermittent — such as development databases, staging environments, or applications with unpredictable traffic patterns — serverless can reduce costs significantly compared to running provisioned instances around the clock.
| Factor | Provisioned Aurora | Aurora Serverless |
|---|---|---|
| Workload type | Steady, predictable | Variable, intermittent |
| Scaling | Manual or with Auto Scaling policies | Automatic within ACU min/max range |
| Cost at low utilisation | Higher (instances always running) | Lower (scales to minimum) |
| Cost at sustained high utilisation | Lower per unit of capacity | Higher per ACU-hour |
| Multi-AZ availability | Optional, configurable | Single AZ (failover recreates in another AZ) |
Availability, Failover, and Limitations
One of the most important architectural differences to understand is how Aurora Serverless handles availability.
- Single AZ compute — A serverless DB cluster runs its compute in a single Availability Zone, unlike provisioned Aurora which can span multiple AZs simultaneously for compute.
- Failover time is undefined — If the AZ hosting your serverless cluster becomes unavailable, Aurora will attempt to recreate it in another AZ. AWS’s own documentation at the time stated: “The Aurora Serverless failover time is currently undefined because it depends on demand and capacity availability.” This is a meaningful caveat for production workloads with strict RTO requirements.
- Data durability is preserved — Because the storage layer always spans multiple AZs, your data is protected even if the compute layer fails. The risk is unavailability, not data loss.
- Warm pool for scaling — AWS maintains a pool of pre-warmed database capacity to accelerate scaling events, which reduces the latency of adding capacity during traffic spikes.
Is Aurora Serverless Right for Your PostgreSQL Workload?
Aurora Serverless is a strong fit for specific use cases, but it is not a universal replacement for provisioned Aurora. Consider the following decision criteria:
- Use serverless if your database has variable or unpredictable traffic, is used intermittently (overnight jobs, scheduled tasks), or is a non-production environment where you want to minimise idle costs.
- Use provisioned if you have a steady, high-throughput production workload, require guaranteed multi-AZ compute redundancy with fast, defined failover times, or need to tightly control and predict your monthly database costs.
Both options carry the premium of a fully managed service: AWS handles patching, backups, monitoring integration, and underlying infrastructure. You are paying for operational simplicity in addition to raw compute and storage.
The Bigger Picture
Aurora Serverless PostgreSQL represents AWS bringing its most cloud-native database deployment model to the most widely used open-source relational database. At launch, the serverless model carried trade-offs — higher per-ACU cost, undefined failover times, and single-AZ compute — that made it unsuitable for the most demanding production workloads. These limitations are consistent with first-generation serverless database products across cloud providers.
The trajectory is clear: serverless database abstractions will continue to mature, narrow the feature gap with provisioned options, and become cost-competitive for a broader range of workloads. For teams evaluating Aurora today, it is worth checking the current AWS documentation for the latest ACU pricing, supported PostgreSQL versions, and any updates to the failover SLA, as these specifics evolve with each Aurora release.
Always consult the official Aurora Serverless documentation and the Aurora pricing page for current figures before making architectural decisions.