Don't be fooled, the compatibility is there so that it's easy to port applications to Aurora, not so it's easy to take them out.
Amazon still offers MySQL RDS. If you move to the much-more-expensive Aurora, it's generally because your MySQL RDS application is struggling, and Amazon says "Aurora knows special tricks to make the engine faster."
Some management headaches, like adjusting for disk growth, are handled by Aurora transparently, which is nice, but for the most part, I saw workloads going to Aurora because they were too slow on standard MySQL.
That means that instead of optimizing or fixing your application, you're relying on a single vendor's Secret Go Juice to make your application usable/performant. In such cases, unless the mainline distribution catches up in the meantime, you're going to be stuck because your stuff will be too slow on other stacks.
From the risk management POV, Aurora is at best a temporary solution while the program is refactored/optimized to be performant on standard distributions.
The second maxim is "no one ever got fired for buying IBM". If you're going to bet on a horse, there is always a chance that things go sideways. You might as well bet on the fastest horse with the best record.
If you had a choice between IBM, DEC VAX, and Stratus VOS back in the day and you went the safe route to go with IBM, you would have been vindicated two decades later. IBM is still selling compatible systems.
I could go through the trouble of staying "vendor neutral" and use tools like Consul+Vault with an AWS backend, Nomad, and Terraform (been there done that) but the time I'm wasting being vendor neutral, I can spin up equivalent services on AWS that cost less and I don't have to maintain them.
Most of the things that I depend on AWS for now, I was doing the equivalent of on prem before and after AWS existed. I'm glad to not have to do that anymore and just being able to press a few buttons.
And on top of that, in the realm of database engineering, Amazon is absolutely a newcomer, they've got another good 15 years before they can even start to be in contention for "reliable and trustworthy database vendor". Goes doubly when you consider that Aurora is essentially just a bunch of performance hacks to (old versions of) InnoDB and Postgres. Presumably, upstreams like MariaDB and PostgreSQL have forgone similar enhancements for a better reason than "only Amazon employees are smart enough to figure it out".
They did hire a bunch of experienced engineers. I'd rather have them actually contribute to postgres (which amazon pretty much doesn't do, some bug reports aside).
> Presumably, upstreams like MariaDB and PostgreSQL have forgone similar enhancements for a better reason than "only Amazon employees are smart enough to figure it out".
Some of them are harder to do if you don't have as much control over the environment as amazon does...
That's why no announcements cover change fundamental change to either database - all the features we're seeing a the kinds you'd do on a personal scale with SSD RAIDs and ZFS (or other copy on write FSes), except on a datacenter scale.
Have you seen the code see to know that they are just “performance hacks”? Have you thought that when you can actually spend millions on a project you might be able to throw some top notch engineers at it?
In general, if you're moving to AWS and just setting up some EC2 instances and using S3 in the fear of one day in the future it may not be what you want, you are wasting money. There are much cheaper pure hosting solutions. The benefits of using AWS is all of the services they provide that keep you from doing the "undifferentiated heavy lifting".