Aurora is a transactional database from Amazon. Its research white paper details the innovative, cloud-native storage engine that distinguishes it from its peers. The thing I find exceptional about it is how durable data is once written to the database’s storage layer - its written 6 times!
Impressively, Aurora is compatible with both PostgreSQL and MySQL. This means that you could move a workload using one of those two databases seamlessly to Aurora. This also means that you could potentially move off of it anytime you want.
One of the underappreciated things about Aurora is how easy it is to start new read replicas, thereby increasing the amount of reads your database cluster can handle. It even has a feature called Parallel Query that allows you to dramatically increase analytical query speed. This makes it an… OK data warehouse.
Aurora is one of the safest, most fault tolerant database out there. This safety has a tradeoff, however. It’s expensive, has a confusing pricing model, and isn’t particularly fast.
Pros
You can choose between a PostgreSQL or MySQL front end. This makes it very flexible and also easy to recruit for.
Spinning up new read replicas is totally painless.
The Parallel Query feature makes it a respectable data warehouse without any need to do ELT.
Aurora’s innovative distributed storage engine makes it incredibly reliable.
Many other databases are compatible with PostgreSQL and MySQL. This means that if you outgrow Aurora at some point in the future (unlikely), you will be able to adopt a different one such as Spanner, CockroachDB, or SingleStore relatively easily.
It is easily deployed via AWS’ RDS service.
You can interact with it via pgAdmin or MySQL Workbench - both great database UI managers.
PostgreSQL and MySQL both have great documentation.
It is expensive, and the pricing system is confusing. I’ve never met anyone who had a good idea how many IOPS they were going to use before starting to use the service.