Using Amazon Aurora to better your software and development team!
May 02, 2017

Using Amazon Aurora to better your software and development team!

Anonymous | TrustRadius Reviewer
Score 7 out of 10
Vetted Review
Verified User

Overall Satisfaction with Amazon Aurora

Amazon Aurora is used by my organization as the backend for our software. Previously, we hosted our own MySQL servers which inevitably due to lack of resources ran behind on updates and thus performed more poorly than it should. Moving to Amazon Aurora has improved performance for a database that was poorly designed at the start and was operating on a slowly outdated MySQL version. Moving to Amazon Aurora not only improved performance, but allows my company to continue with fewer resources but yet have the advantage of a database that is more stable and stays up to date with the latest features. Since moving to Amazon Aurora, we also have fewer replication errors since Aurora does this flawlessly.
  • Automated maintenance for upgrades is by far the most superior feature of Amazon Aurora. Never be behind on upgrades again!
  • Performance improvements for poorly structured schema due to enhancements added by Amazon.
  • Replication works flawlessly due to added security measures added into Amazon Aurora which prevents admin users from "accidentally" breaking the slave instance.
  • Amazon Aurora is hosted on Amazon's RDBMS which also includes quick and easy setup of new database instances.
  • I'd like to see Amazon Aurora get ahead of the curve on MySQL and introduce their own improvements to MySQL to make it a superior database so that I don't need to use SQL Server or Oracle to get performance improvements. For example, improve performance of views.
  • Amazon Aurora needs to improve the ability to restore backups as needed. Currently, the user can only restore an entire instance to a new or existing RDBMS instance. If you need to retrieve data from a single table, this can be tedious after waiting hours for an entire restore to complete. Instead, allow the user to select a database to restore. Better yet, allow the user to restore a database backup to ANOTHER database - which would allow you to restore a database on the same instance.
  • Again beat MySQL to the punch and introduce REAL server to server communication since they have disabled the "Federated Engine" which was the only way previously to do this. I'd like to be able to setup MySQL instances to talk to other MySQL instances.
  • The main positive for my team is the time that has been freed up from the tasks of managing updates and fixing replication issues.
  • A negative for myself as a database administrator is removal of features that were available in MySQL. Examples include 1) the use of the storage engines other than InnoDB (such as the Federated Storage Engine), 2) certain administrative privileges such as ability to export to csv file and easy ability to kill processes. I seem to also forget they removed the built-in kill ability and you must use their own provided kill functionality.
In the end, we went with Amazon Aurora due to the decent performance and cost. Cost was determined in two ways for us: 1) no additional license is required (such as using SQL Server or Oracle) and 2) the ability to cut down on needed resources to maintain the system from the maintenance perspective due to the built-in maintenance capabilities. Amazon Aurora is also based on MySQL (soon to include PostgreSQL ) which allowed my team to quickly and easily move our existing MySQL servers to a faster system.
Amazon Aurora (as is MySQL) is better suited for light to medium applications considering it still has some performance limitations from MySQL. I would not recommend it for enterprise level use without a carefully constructed backend system (code and database). My company's current backend architecture was not mapped out very well and this leads to performance problems that even Amazon Aurora has not been able to completely sort (although it has been a huge help).

Another area where I am finding it beginning to lack is for use in data warehousing. The more rows added, the less performant I'm finding the data warehouse. Although to be fair, Amazon has another product (Redshift) that we are looking to migrate data warehouses into.