Amazon Aurora

Compatible with, not the same as

The first thing to be precise about is what Aurora is, because the compatibility framing invites a misunderstanding.

Amazon RDS runs the standard engines. PostgreSQL on RDS is PostgreSQL.

Aurora is a database Amazon built. It presents interfaces compatible with PostgreSQL and MySQL, so applications written for those engines generally work against it. Underneath, particularly in how storage works, it is a different design.

The practical effect of compatibility is real. Drivers connect. SQL runs. Tools work. Most applications move without being rewritten.

The practical effect of the difference is also real. Behaviour, performance characteristics and available features are not identical, and the official documentation lists what differs. Checking that list before a migration is the difference between a straightforward move and an unpleasant discovery.

The idea underneath

The design choice that distinguishes Aurora is separating storage from compute.

In a conventional database, one server holds both the process answering queries and the data on its disks. A read replica is another server with its own copy of the data, kept in step by replication.

Aurora separates these. There is a storage layer holding the data, distributed across availability zones. Instances that process queries access that shared storage.

Several consequences follow, and they are the substance of what the service offers.

Replicas are quick to create. A read replica is an instance connecting to storage that already exists. There is no copy to make, which changes replica creation from an operation measured in hours on a large database to something much shorter.

Storage grows on its own. It expands as data grows rather than requiring someone to extend a volume before it fills.

Durability is inherent. Data is held across availability zones by the storage layer itself rather than through replication that has to be configured and monitored.

Failover does not move data. If a writer instance is lost, another instance takes over against the same storage rather than a replica being promoted with its own copy.

Where this fits

The natural comparison is with RDS, and the choice between them is a real one rather than a matter of one superseding the other.

RDS runs the actual engines. Behaviour matches the engine exactly, versions follow the upstream projects, and moving a database off it is comparatively straightforward.

Aurora offers the storage architecture and the operational properties that follow from it, in exchange for running an Amazon implementation with compatibility interfaces.

For many workloads RDS is entirely adequate and simpler to reason about. Aurora becomes interesting where read capacity has to be added quickly, where the workload is demanding enough that the storage design matters, or where the availability characteristics are specifically wanted.

What stays the same

Managed operation covers infrastructure, not usage.

Queries still need to be efficient. Indexes still determine whether a query is fast. Schema design still matters, and a poorly designed schema on Aurora is a poorly designed schema.

Read replicas serve reads and do not absorb write load. A write heavy workload beyond what the writer instance handles is not addressed by adding replicas, which is a common misunderstanding about read scaling generally.

Who uses it

Aurora is used by application teams and platform teams on AWS running relational workloads with demanding performance or availability requirements. It is a frequent destination for PostgreSQL and MySQL databases moving to AWS where the standard managed service is not sufficient.

Points to consider

Aurora is an AWS service and runs only there. Application level compatibility with PostgreSQL and MySQL means the application is not locked in, and the deployment is.

Pricing differs from RDS in structure, covering instance capacity, storage and requests against storage. Comparing the two requires understanding how each is measured rather than comparing instance prices.

Compatibility is documented and should be checked rather than assumed. Versions supported, features available and behavioural differences are all in the documentation, and applications using unusual features are where surprises occur.

Serverless options exist within the Aurora family with different scaling and pricing behaviour, described in the same documentation, and they suit intermittent workloads better than provisioned instances do.

Getting started

The official documentation covers compatibility, cluster architecture, replicas and failover. Creating a cluster and adding a read replica demonstrates the shared storage design immediately, because the replica becomes available far faster than copying the data would allow.