We've switched 6 or 7 of our production databases to Aurora now. It is <i>much</i> faster than MySQL/Percona Server. Even highly optimized MySQL installs with FusionIO cards struggled to keep up before we switched to Aurora.<p>Aurora is expensive, but it's a huge instant speedup and easily worth the cost for anyone with a production application that occasionally hits performance limitations on traditional MySQL.<p>That said, it is based on MySQL 5.6.10, so we are missing some features like online DDL from 5.6.17. Many bugs from 5.6.10 have been resolved upstream but are still present in Aurora. [0] It's also subject to the usual limitations of RDS (no SUPER, no access to the binary database files, no innobackupex).<p>[0] <a href="https://www.percona.com/blog/2015/11/16/amazon-aurora-looking-deeper/" rel="nofollow">https://www.percona.com/blog/2015/11/16/amazon-aurora-lookin...</a>
Cool, although I sure wish they had gone with Postgres. I can't live without the occasional JSONB anymore.<p>I know MySQL has made some half-hearted attempts to make headway on this front, but it has completely changed the way I model certain parts of my data.
Aurora being a closed-source fork of MySQL is a real problem in my opinion.<p>Look at all the comments here about new features and bug fixes introduced upstream but missing in 5.6.10 (online DDL, JSON, etc.).<p>We already have Oracle's MySQL, MariaDB, WebScaleSQL, MyRocks (Facebook's MySQL with RocksDB and DocStore), Percona Server for MySQL, and now Aurora. Each version has its own features and peculiarities. The ecosystem is too much scattered.
MySQL compatible means that moving from MySQL to Aurora is transparent to the application, included all the MySQL (InnoDB?) peculiarities, which many regard as bugs?<p>This could be really important because some applications end up relying on MySQL oddities even with good willed developers.