Amazon Aurora

The support as a whole cannot be applied to just Aurora, but I must say that the response to our tickets from the AWS side was a bit anemic. Despite that, there is plenty of documentation and forum articles that should make anybody self-serviced. Again, let me stress this out - the product (in either MySQL or Postgres form) was used by many people and thus now well understood, explained and there are plenty of books and other material available. This is not the case that we encountered with NoSQL.

Aurora is great for situations where databases require autoscaling and need high availability. For example, high traffic websites running on an autoscaling compute layer can benefit by being connected to a datastore that can scale along with them. Also any scenario that requires fault tolerance can benefit greatly from Aurora. Knowing that your DB can heal itself (to the best of its ability) can give developers and engineers confidence that their application will handle adverse scenarios in the event of failure conditions. Given the premium of running DBs with Aurora, I would not recommend using it for development environments. Given that Aurora is compatible with most common DB software, development environments can use cheaper, smaller RDS instances. When it comes time for deploying into a production environment, no changes would be needed.

AWS has been top notch in providing support for Aurora and RDS as a whole. For the most part, there is rarely ever a need to request support for our database deployments. The only interactions I can think of off hand are asking for increases in the number of instances we can deploy.

Aurora is easy to deploy and operate from the AWS console, the command line, and with Infrastructure as Code tools like Cloudformation and Terraform. Integrating the endpoints into an application is easy because from the outside, the Aurora clusters look just like any other open source database. I have also seen benefit from using the instances within the cluster as distinct read and write endpoints allowing for further customization in our applications.

It's not obvious to plan database capacity for a year out, so I usually avoid buying reserved instances. However, the ability to buy “Reserved ACUs” would be something interesting concept. That way you could prepay for hours of capacity at a discounted rate. If your load is stable but peaks at certain times, go for an Aurora Serverless, it will be way cheaper than reserved instances.

I never had issues with Aurora that forced me to deal with support. It has been stable and reliable so far, at least in my experience and my team's.

Variable read load. Being able to autoscale your DB is amazing. Operationally, not worrying about failover is also amazing. Outside of Aurora/RDS, Postgres failover is always a big pain. Even on plain RDS, there's some concern with data loss in a failover.

We've hit a number of known bugs and have to wait for a minor release to get them fixed. We've also hit some reproducible bugs and we're met with a lot of resistance from support as we shared them.