Amazon Aurora vs Presto

• 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.

Read full review

• Fast - Presto, is incredibly fast due to its optimized query engine and is well suited for interactive analysis.
• Flexible - Presto is highly flexible as it operates with a plug and play model for data sources. Joining and query across different data sources is very easy with presto (eg. HDFS, MySQL, Kafka).
• ANSI Sql - Presto follows ANSI SQL which is the recognized SQL language and hence helps allow easy query migration without much overhead.
• Large Fact + Small Dimension table joins made fast - By design presto excels most distributed query engines out there in this type of queries.

Read full review

• 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.

Read full review

• Presto was not designed for large fact fact joins. This is by design as presto does not leverage disk and used memory for processing which in turn makes it fast.. However, this is a tradeoff..in an ideal world, people would like to use one system for all their use cases, and presto should get exhaustive by solving this problem.
• Resource allocation is not similar to YARN and presto has a priority queue based query resource allocation..so a query that takes long takes longer...this might be alleviated by giving some more control back to the user to define priority/override.
• UDF Support is not available in presto. You will have to write your own functions..while this is good for performance, it comes at a huge overhead of building exclusively for presto and not being interoperable with other systems like Hive, SparkSQL etc.

Read full review

• 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.

Read full review

• Presto has helped scale Uber's interactive data needs. We have migrated a lot out of proprietary tech like Vertica.
• Presto has helped build data driven applications on its stack than maintain a separate online/offline stack.
• Presto has helped us build data exploration tools by leveraging it's power of interactive and is immensely valuable for data scientists.

Read full review