Amazon RDS vs Amazon Redshift

• Multiple availability zones for high assurance of uptime
• Both hosted and local management/reporting utilities
• Integration with CloudWatch and CloudFormation for automated creation and real-time performance metrics

Read full review

• Redshift seems to be as fast processing a large dataset as it is with a small one. It seems, when the dataset size is significantly increased (10x, 100x, 1000x, etc.), DML queries are often executed within the same amount of time.
• Redshift has a powerful graphical admin tool to monitor the ongoing queries in real time and historically.
• Easily expandable capacity. Automatic snapshots that eliminate the need for managing backups. Simple database maintenance strategies with the VACUUM and ANALYZE commands.
• Abundance of detailed documentation and tutorials.

Read full review

• Cross-Region replication is supported for most platforms and engines, but is not available across the board yet. Where it is available it provides an excellent solution for disaster recovery.

Read full review

• It could benefit from adding data integrity and programming tools common to other database management systems.
• Amazon Redshift is based on PostgreSQL 8.0.2. That version of PostgreSQL was released in December 2006. While PostgreSQL was much improved since then, the new features were not implemented in Redshift. Many basic features are missing from it.
• Primary keys can be declared but not enforced. Referential integrity (foreign keys) can be declared but not enforced. UNIQUE and CHECK constraints are not supported and cannot be declared.
• IDENTITY can be declared on a column, and Redshift will put unique values into it. However: IDENTITY values in the newly inserted rows won’t be incremental or sequential. To implement a sequential number, you need to write your own custom code.
• There are no stored procedures in Redshift. We are writing SQL script files, and then parsing and running them one statement at a time from a Python program. This also enabled us to implement execution-time error logging.
• In SQL scripts, to check for the row count of affected rows, a complicated join query against some system tables or views has to be executed.
• Data Control Language (DCL) does not exist. No statements like IF, WHILE, DO, RAISERROR, etc.
• On performance of views… Views do not “pass-through” a query parameter which is a potential problem for performance.
• When selecting against a view with the WHERE clause outside of the view, the inner query of the view will be executed first without consideration for the WHERE clause, and only then the WHERE clause will be applied.
• Certain clauses of SQL work many times faster than other clauses. So be careful and test your statements for performance earlier rather than later, especially if working with a large data set.
• There was a situation when DELETE FROM JOIN was unacceptably slow. Replacing JOIN with the USING clause made DELETE instantaneous.

Read full review

• Very positive. It has reduced our need to have IT Operations and DBA resources, and with Aurora we have been able to get better performance with less compute power required (that is, with a lower monthly spend).

Read full review

• Redshift has enabled us to expose more of our product and business performance data which was previously not accessible or reportable.
• We can now make data driven decisions for our business.

Read full review