5 reasons why HeatWave on OCI is better than Amazon Redshift
Here are the top five reasons to choose HeatWave on Oracle Cloud Infrastructure (OCI) over Amazon Redshift.
- Simplicity: HeatWave enables automated and integrated generative AI and machine learning (ML) in one cloud service for transactions and lakehouse-scale analytics. Customers can eliminate the complexity, latency, cost, and risks of ETL duplication across cloud services.
- Automated and integrated generative AI: Oracle HeatWave GenAI provides automated and integrated generative AI with in-database large language models (LLMs); an automated, in-database vector store; scale-out vector processing; and the ability to have contextual conversations in natural language—letting you take advantage of generative AI without AI expertise or data movement.
- Better performance and price performance: Oracle HeatWave MySQL is 4X faster than Amazon Redshift, delivering 10X better price-performance. The query performance of HeatWave Lakehouse is 15X faster than Amazon Redshift, delivering 11X better price-performance for query processing. Oracle HeatWave AutoML trains models 25X faster than Redshift ML at 1% of the cost.
- Machine learning–powered automation: Oracle HeatWave Autopilot provides workload-aware, machine learning–powered automation of various aspects of the application lifecycle, including provisioning, data loading, query execution, and failure handling.
- Increased data protection: HeatWave eliminates the risk of data movement between data stores and provides advanced security features to protect data throughout its lifecycle and support compliance with regulatory requirements.
1. Simplicity
Capability and evidence |
HeatWave |
Amazon Redshift |
|---|---|---|
One cloud database service for OLTP and OLAP across data warehouses and data lakes |
yes
Customers can run both OLTP and analytics workloads across data warehouses and data lakes in a single cloud database service—without changes to existing MySQL and Aurora-based applications. For mixed OLTP and OLAP workloads, applications access a single endpoint using a single SQL syntax. |
no
Amazon Redshift is a forked version of PostgreSQL without OLTP capabilities. Customers require a separate OLTP database. For mixed OLTP and OLAP workloads, applications must access two different endpoints using two different SQL syntaxes. |
No ETL duplication |
yes
The complex, time-consuming, and expensive ETL is eliminated. |
no
Single-purpose databases require an ETL process to move data between OLTP and OLAP services. Although the “zero-ETL” integration of Amazon Aurora and Redshift simplifies the process, data is still replicated between two separate database services for OLTP and OLAP, creating complexity and generating costs (more details are in section 3). |
Real-time analytics |
yes
Queries always access the most up-to-date data; there’s no data transfer between databases. |
no
By the time data goes through ETL and is available in Redshift, it’s already stale. Even with zero-ETL integration between Aurora and Redshift, the latency of replicating data between two databases can be problematic for applications requiring real-time analytics. |
In-database machine learning |
yes
With HeatWave AutoML, developers and data analysts can build, train, deploy, and explain machine learning models within HeatWave. Data and ML models don’t leave the database, which speeds up results and prevents the risks of data movement between data stores. |
no
A separate ML service, such as Amazon SageMaker, is required—even when using Redshift ML. Data is copied to a separate location, and ML models are built outside Redshift. |
Automated machine learning lifecycle |
yes
The ML lifecycle is fully automated, including algorithm selection, intelligent data sampling, feature selection, and hyperparameter tuning for all model types. |
no
Redshift ML requires data science expertise to select the best algorithm and influence the performance, accuracy, and cost of training. |
Explainable data models and predictions |
yes
All ML models and predictions are explainable, increasing trust, fairness, causality, and repeatability and helping with regulatory compliance. |
no
Predictions from ML models in Redshift ML aren’t explainable, which may reduce trust, increase risks for bias, and could make regulatory compliance more difficult. |
2. Automated and integrated generative AI
Capability and evidence |
HeatWave |
Amazon Redshift* |
|---|---|---|
In-database LLMs |
Customers can use in-database, optimized LLMs across clouds and regions without the hassle of external LLM selection and integration. They can also choose external LLMs if needed. HeatWave helps customers significantly reduce infrastructure costs by eliminating the need to provision GPUs. | With Amazon Redshift, users must use a separate service, Amazon SageMaker, to provide LLM models and manually import them into the Redshift database. |
Automated generation of vector embeddings |
HeatWave helps automate the generation of vector embeddings, including parsing, extracting metadata, creating chunks, and choosing embedding models for both data and queries—without requiring AI expertise. All steps are completed in-database without requiring data movement to separate client resources, simplifying the process and helping reduce costs. | Amazon Redshift doesn’t currently support in-database vector processing. |
Accelerated vector processing |
Vector processing is parallelized across up to 512 HeatWave cluster nodes and executed at memory bandwidth, helping deliver fast results at an improved speed. | Amazon Redshift doesn’t currently support in-database vector processing. |
HeatWave Chat interface |
HeatWave Chat lets users have natural language conversations informed by their unstructured documents. The context is preserved for follow-up questions. Developers don’t need to build a separate chat user interface, which helps accelerate the development cycle of GenAI apps. | AWS doesn’t provide an “out-of-the-box” interface. Users need to use a separate service to build a chatbot, which may increase complexity and costs. |
*As of June 20204
3. Better performance and price-performance
According to a 10 TB TPC-H benchmark, HeatWave is 4X faster than Amazon Redshift.
| Service | Average execution time in seconds (Geomean) |
|---|---|
| HeatWave MySQL (10 nodes) | 14.23 |
| Amazon Redshift (10 nodes of ra3.4xlarge) | 59 (4X slower) |
Capability and evidence |
HeatWave |
Amazon Redshift |
|---|---|---|
Real-time elasticity without downtime or read-only time |
yes
Customers can increase or decrease the size of their HeatWave cluster by any number of nodes without incurring any downtime or read-only time. Data is automatically rebalanced among all available cluster nodes for high performance. |
no
With elastic resize, the Redshift cluster is unavailable for four to eight minutes of the resize period. There are several limitations to consider, and the elastic resize of the Redshift cluster can cause data skew between nodes from an uneven distribution of data slices—which can severely downgrade the performance of queries. |
Compared with Amazon Redshift, HeatWave MySQL provides 10X better price-performance, as demonstrated by a 10 TB TPC-H benchmark.
| Service | Price-performance |
|---|---|
| HeatWave MySQL (10 nodes) | 1,00 |
| Amazon Redshift (10 nodes of ra3.4xlarge) | 10,10 (10X worse) |
Note: This comparison doesn’t consider that with Amazon Redshift you need to pay for a separate OLTP database, such as Amazon Aurora, and for the data transfer between the two databases—which you can avoid with HeatWave MySQL. Hence, the savings can be greater with HeatWave MySQL.
As demonstrated by a 500 TB TPC-H benchmark, the query performance of HeatWave Lakehouse is 15X faster than Amazon Redshift, delivering 11X better price-performance. The load performance is 9X faster than Redshift.
| Service | Total query time in seconds |
|---|---|
| HeatWave Lakehouse (512 nodes) | 2000 |
| Amazon Redshift (20-ra3.16xlarge) | 32500 (15X slower) |
| Service | Price-performance |
|---|---|
| HeatWave Lakehouse (512 nodes) | 140 |
| Amazon Redshift (20-ra3.16xlarge) | 1540 (11X worse) |
Benchmarks also demonstrate that, on average, HeatWave AutoML produces more accurate results than Amazon Redshift ML, trains models 25X faster, and is 1% of the cost.
Amazon Web Services notes that while it doesn’t charge an additional fee for Aurora zero-ETL integration with Redshift, “you pay for existing Aurora and Amazon Redshift resources used to create and process the change data created as part of a zero-ETL integration. These resources could include:
- Additional I/O and storage used by enabling change data capture
- Snapshot export costs for the initial data export to seed your Amazon Redshift databases
- Additional Amazon Redshift storage for storing replicated data
- Additional Amazon Redshift compute for processing data replication
- Cross-AZ data transfer costs for moving data from source to target”
4. Machine learning–powered automation
Capability and evidence |
HeatWave |
Amazon Redshift |
|---|---|---|
Automated query performance tuning |
yes
HeatWave Autopilot learns from the execution of queries and uses machine learning to automatically improve the performance of subsequent queries. |
no
Query plans aren’t automatically improved using machine learning models. |
Automated provisioning of the optimal cluster size |
yes
HeatWave Autopilot uses machine learning to automatically provision the optimal cluster size for a given data set, whether the data resides in MySQL or in the object store. |
no
With Redshift, users need to answer questions to get a recommendation on the cluster size to provision. |
Automated data loading |
yes
HeatWave Autopilot analyzes the data in the object store to predict the load time into the in-memory HeatWave cluster and automatically loads the data. |
no
Redshift doesn’t predict the load time into the cluster, making planning more difficult for DBAs. |
5. Increased data protection
Capability and evidence |
HeatWave |
Amazon Redshift |
|---|---|---|
No ETL process |
yes
The risk of data movement between data stores is eliminated. |
no
Data security and regulatory compliance risks can increase as data moves between separate services for OLTP, OLAP, and ML. Even with zero-ETL integration between Aurora and Redshift, data moves between two separate services. |
Digital signatures to confirm the authenticity and integrity of messages |
yes
Built-in server-side asymmetric encryption with key generation and digital signatures is provided. |
no
Built-in server-side asymmetric encryption to implement digital signatures isn’t provided. |
Built-in server-side data masking |
yes
Data masking and deidentification are built-in, helping protect the confidentiality of private data. |
no
Data masking and deidentification need to be implemented at the application level. |
Try HeatWave for free.