HeatWave MySQL Performance

Performance comparison of HeatWave MySQL on OCI with Snowflake, Amazon Redshift, Amazon Aurora, and Amazon RDS for MySQL

Several performance comparisons have been run and the results are presented below. They focus on two different aspects.

• Query processing
  The performance comparison encompasses a variety of benchmarks—TPC-H, TPC-DS, and CH-benCHmark with different data set sizes (4 TB and 10 TB) to validate the speedup provided by HeatWave.
• Machine learning
  The performance experiments use a wide variety of publicly known data sets for machine learning classification and regression problems.

1. Common setup for analytic (OLAP) workload test for TPC-H and TPC-DS

• The workload is derived from the TPC’s TPC-H and TPC-DS benchmarks.*
• Generate data using the corresponding data generation tool.
• Provision and configure the target service.
• Create the corresponding schema on the target service instance.
• Import the data generated to the target service instance.
• Run queries derived from TPC-H or TPC-DS to test the performance.
• For best performance numbers, always do multiple runs of the query and ignore the first (cold) run.
• You can always do an explain plan to make sure you get the best expected plan.

2. Common setup for mixed workload test

• The workload is derived from CH-benCHmark.**
• The OLTPBench framework (with changes made to support HeatWave) was used to run the mixed workload benchmark.
• Provision and configure the target service instance.
• Create the mixed workload schema (TPC-C and CH-benCH) on the target service instance.
• Generate and load the 1,000 warehouse (100 GB) data set to the target service instance.
• Set the incoming rate of TPC-C transactions at 500 per second (30K transactions per minute) and the incoming rate of CH-benCH transactions at 4 per second (240 transactions per minute).
• Run 128 concurrent sessions of TPC-C (OLTP) and 4 concurrent sessions of CH-benCH (OLAP).
• Note the OLTP and OLAP throughput and average latency as reported.

3. HeatWave specific setup

• Optimal encodings are used for certain columns that will be loaded into HeatWave.
• Custom data placement is used for certain tables that will be loaded into HeatWave.
• Mark the tables as offloadable and load them into HeatWave.
• For each query, force offload to HeatWave using the hint (set_var(use_secondary_engine=forced)).
• A straight_join hint is required for certain queries to get the optimal query plan for HeatWave.
• For a detailed setup, reference the following:
  • HeatWave TPC-H GitHub for TPC-H.
  • HeatWave GitHub for TPC-DS and CH-benCHmark.

4. Snowflake on AWS specific setup

• For TPC-H, use clustering on ORDERS(o_orderdate) and LINEITEM(l_shipdate) tables.
• You can also try without clustering and pick the scheme that gives better performance.

5. Amazon Redshift specific setup

• Determine the best shape and cluster size for the experiments. In our experiments, we used ra3.4xlarge instance shape.
• For efficient data ingestion, follow the guidelines for enhanced VPC routing.
• Use the default parameters as specified by the Amazon documentation.
• Make sure the sort keys and distribution keys for each table are optimal for queries. The scripts provided by awslabs can be used for reference.

6. Amazon Aurora specific setup

• Use the largest shape possible so as much of the data can fit into the buffer cache as possible.
• For the 4 TB TPC-H data sets
  • Use the db.r5.24xlarge shapes.
  • Set the innodb_buffer_pool size to 630 GB.
  • Other settings that were modified from their default value in our TPC-H experiments are innodb_sort_buffer_size=67108864; lock_wait_timeout =86400; max_heap_table_size=103079215104; and tmp_table_size=103079215104.
• For the 1,000 warehouse TPC-C data set (used in mixed workload tests)
  • Use the db.r5.8xlarge shape.
  • Use the default parameter settings for innodb_buffer_pool and other parameters.
  • Disable the result cache.
  • Enable parallel query.
• Set aurora_disable_hash_join = 0 and aurora_parallel_query = ON to use parallel query.
• Follow the best practices for Aurora database configuration for any other tuning.
• For parallel query to work, make sure none of the tables are partitioned.
• A straight_join hint can be used if the query plan looks suboptimal.

7. Amazon RDS for MySQL specific setup

• Use the largest shape possible so as much of the data can fit into the buffer cache as possible.
• For the 4 TB TPC-H data sets, use the db.r5.24xlarge shape.
• Set the innodb_buffer_pool size to 650 GB.
• Other settings that were modified from their default value in our TPC-H experiments are innodb_buffer_pool_instances=64; innodb_page_cleaners=64; innodb_read_io_threads=64; temptable_max_ram=64424509440; max_heap_table_size=103079215104; and tmp_table_size=103079215104.
• Follow the best practices for Amazon RDS for any other tuning.
• Make sure all the primary and foreign key indexes are created.
• A straight_join hint can be used if the query plan looks suboptimal.

8. Results

Notes:

1. All costs include only the cost of compute. Storage costs aren’t included and are extra.
2. Redshift pricing is based on one-year reserved instance pricing (paid all upfront).
3. Snowflake pricing is based on standard edition on-demand pricing.
4. Google BigQuery pricing is based on annual flat-rate commitment (per 100 slots).
5. Azure Synapse pricing is based on the one-year reserved instance.

TPC-H results

TPC-DS results

Mixed benchmark results

Performance comparison of HeatWave AutoML with Redshift ML

Below is a setup for the comparison of two different ML problems: classification and regression. For a detailed setup, reference the HeatWave AutoML code for performance benchmarks on GitHub.

1. Common setup

• Datasets listed below are publicly available. Select a dataset to start your test.

  Datasets for classification

  Dataset	Explanation	Rows (training set)	Features
  Airlines	Predict flight delays.	377,568	8
  Bank Marketing	Direct marketing—banking products.	31,648	17
  CNAE-9	Documents with free text business descriptions of Brazilian companies.	757	857
  Connect-4	8-ply positions in the game of connect-4, in which neither player has won yet—predict win/loss.	47,290	43
  Fashion MNIST	Clothing classification problem.	60,000	785
  Nomao	Active learning is used to efficiently detect data that refers to the same place, based on the Nomao browser.	24,126	119
  Numerai	Data is cleaned, regularized, and encrypted global equity data.	67,425	22
  Higgs	Monte Carlo simulations.	10,500,000	29
  Census	Determine if a person’s income exceeds $50,000 a year.	32,561	15
  Titanic	Survival status of individuals.	917	14
  Credit Card Fraud	Identify fraudulent transactions.	199,364	30
  KDD Cup (appetency)	Predict the propensity of customers to buy new products.	35,000	230

  Datasets for regression

  Dataset	Explanation	Rows (training set)	Features
  Black Friday	Customer purchases on Black Friday.	116,774	10
  Diamonds	Predict the price of a diamond.	37,758	17
  Mercedes	Time the car took to pass testing.	2,946	377
  News Popularity	Predict the number of times articles were shared on social networks.	27,750	60
  NYC Taxi	Predict the tip amount for a New York City taxicab.	407,284	15
  Twitter	The popularity of a topic on social media.	408,275	78

• For each dataset, use 70% of the data for training and 30% of the data for testing. We recommend randomly selecting training data from the data set.
• Compute balanced accuracy for classification and R2 regression for regression on the test set.

2. HeatWave AutoML specific setup

• Use a HeatWave cluster with two HeatWave nodes.
• Run ML_TRAIN with the default arguments, and set task to classification or regression based on the dataset type.
• Score the generated model using ML_SCORE, with the metric set to balanced_accuracy for classification and R2 for regression.

3. Amazon Redshift ML specific setup

• Use a Redshift cluster with two nodes on ra3.4xlarge shape.
• Run CREATE_MODEL with the default values of MAX_CELLS (1M) and MAX_RUNTIME (5400s).
  • For the classification dataset, don't specify problem_type and let SageMaker detect the problem type.
  • For the regression dataset, run CREATE_MODEL with PROBLEM_TYPE being REGRESSION.
• Create custom SQL scoring functions to calculate balanced accuracy for classification and R2 for regression.

4. Setup for scalability test

• Test with 2, 4, 8, and 16 HeatWave node cluster.
• Run ML_TRAIN on all datasets described in the common setup section.
• Compute HeatWave AutoML versus Redshift ML speedup for training on every dataset via the following:
  • (Redshift ML default training time budget (90 minutes)) / (HeatWave AutoML end-to-end ML_TRAIN time)
• Compute the geometric mean of speedup across the datasets for each of the cluster configurations.
• Once all five geometric mean speedup values are obtained, plot the geomean speedup (y-axis) versus the cluster size (x-axis).

5. Results

Performance comparison of HeatWave MySQL on OCI with Snowflake, Amazon Redshift, Amazon Aurora, and Amazon RDS for MySQL

Several performance comparisons have been run and the results are presented below. They focus on two different aspects.

• Query processing
  The performance comparison encompasses a variety of benchmarks—TPC-H, TPC-DS, and CH-benCHmark with different data set sizes (4 TB and 10 TB) to validate the speedup provided by HeatWave.
• Machine learning
  The performance experiments use a wide variety of publicly known data sets for machine learning classification and regression problems.

1. Common setup for analytic (OLAP) workload test for TPC-H and TPC-DS

• The workload is derived from the TPC’s TPC-H and TPC-DS benchmarks.*
• Generate data using the corresponding data generation tool.
• Provision and configure the target service.
• Create the corresponding schema on the target service instance.
• Import the data generated to the target service instance.
• Run queries derived from TPC-H or TPC-DS to test the performance.
• For best performance numbers, always do multiple runs of the query and ignore the first (cold) run.
• You can always do an explain plan to make sure that you get the best expected plan.

2. Common setup for mixed workload test

• The workload is derived from CH-benCHmark.**
• The OLTPBench framework (with changes made to support HeatWave) was used to run the mixed workload benchmark.
• Provision and configure the target service instance.
• Create the mixed workload schema (TPC-C and CH-benCH) on the target service instance.
• Generate and load the 1,000 warehouse (100 GB) data set to the target service instance.
• Set incoming rate of TPC-C transactions at 500 per second (30K transactions per minute) and incoming rate of CH-benCH transactions at 4 per second (240 transactions per minute).
• Run 128 concurrent sessions of TPC-C (OLTP) and 4 concurrent sessions of CH-benCH (OLAP).
• Note the OLTP and OLAP throughput and average latency as reported.

3. HeatWave specific setup

• Optimal encodings are used for certain columns that will be loaded into HeatWave.
• Custom data placement is used for certain tables that will be loaded into HeatWave.
• Mark the tables as offloadable and load them into HeatWave.
• For each query, force offload to HeatWave using the hint (set_var(use_secondary_engine=forced)).
• A straight_join hint is required for certain queries to get the optimal query plan for HeatWave.
• For detailed setup, reference the following:
  • HeatWave TPC-H GitHub for TPC-H.
  • HeatWave GitHub for TPC-DS and CH-benCHmark.

4. Snowflake on AWS specific setup

• For TPC-H, use clustering on ORDERS(o_orderdate) and LINEITEM(l_shipdate) tables.
• You can also try without clustering and pick the scheme that gives better performance.

5. Amazon Redshift specific setup

• Determine the best shape and cluster size for the experiments. In our experiments, we used ra3.4xlarge instance shape.
• For efficient data ingestion, follow the guidelines for enhanced VPC routing.
• Use the default parameters as specified by the Amazon documentation.
• Make sure that the sort keys and distribution keys for each table are optimal for queries. The scripts provided by awslabs can be used for reference.

6. Amazon Aurora specific setup

• Use the largest shape possible so that as much of the data can fit into the buffer cache as possible.
• For the 4 TB TPC-H data sets
  • Use the db.r5.24xlarge shapes.
  • Set the innodb_buffer_pool size to 630 GB.
  • Here are other settings that were modified from their default value in our TPC-H experiments: innodb_sort_buffer_size=67108864; lock_wait_timeout =86400; max_heap_table_size=103079215104; tmp_table_size=103079215104.
• For the 1,000 warehouse TPC-C data set (used in mixed workload tests)
  • Use the db.r5.8xlarge shape.
  • Use the default parameter settings for innodb_buffer_pool and other parameters.
  • Disable result cache.
  • Enable parallel query.
• Set aurora_disable_hash_join = 0 and aurora_parallel_query = ON to use parallel query.
• Follow the best practices for Aurora database configuration for any other tuning.
• For parallel query to work, make sure that none of the tables are partitioned.
• A straight_join hint can be used if the query plan looks suboptimal.

7. Amazon RDS for MySQL specific setup

• Use the largest shape possible so that as much of the data can fit into the buffer cache as possible.
• For the 4 TB TPC-H data sets, use the db.r5.24xlarge shape.
• Set the innodb_buffer_pool size to 650 GB.
• Here are other settings that were modified from their default value in our TPC-H experiments: innodb_buffer_pool_instances=64; innodb_page_cleaners=64; innodb_read_io_threads=64; temptable_max_ram=64424509440; max_heap_table_size=103079215104; tmp_table_size=103079215104.
• Follow the best practices for Amazon RDS for any other tuning.
• Make sure all the primary and foreign key indexes are created.
• A straight_join hint can be used if the query plan looks suboptimal.

8. Results

Notes:

1. All costs include only the cost of compute. Storage costs aren’t included and are extra.
2. Redshift pricing is based on one-year reserved instance pricing (paid all upfront).
3. Snowflake pricing is based on standard edition on-demand pricing.
4. Google BigQuery pricing is based on annual flat-rate commitment (per 100 slots).
5. Azure Synapse pricing is based on the one-year reserved instance.

TPC-H results

TPC-DS results

Mixed benchmark results

Performance comparison of HeatWave AutoML with Redshift ML

Setup for the comparison of two different ML problems: classification and regression. For detailed setup, reference the HeatWave AutoML code for performance benchmarks on GitHub.

1. Common setup

• Datasets listed below are publicly available. Select a dataset to start your test.

  Datasets for classification

  Dataset	Explanation	Rows (Training set)	Features
  Airlines	Predict flight delays.	377,568	8
  Bank Marketing	Direct marketing—banking products.	31,648	17
  CNAE-9	Documents with free text business descriptions of Brazilian companies.	757	857
  Connect-4	8-ply positions in the game of connect-4, in which neither player has won yet—predict win/loss.	47,290	43
  Fashion MNIST	Clothing classification problem.	60,000	785
  Nomao	Active learning is used to efficiently detect data that refers to the same place, based on the Nomao browser.	24,126	119
  Numerai	Data is cleaned, regularized, and encrypted global equity data.	67,425	22
  Higgs	Monte Carlo simulations.	10,500,000	29
  Census	Determine if a person’s income exceeds $50,000 a year.	32,561	15
  Titanic	Survival status of individuals.	917	14
  Credit Card Fraud	Identify fraudulent transactions.	199,364	30
  KDD Cup (appetency)	Predict the propensity of customers to buy new products.	35,000	230

  Datasets for regression

  Dataset	Explanation	Rows (Training set)	Features
  Black Friday	Customer purchases on Black Friday.	116,774	10
  Diamonds	Predict the price of a diamond.	37,758	17
  Mercedes	Time the car took to pass testing.	2,946	377
  News Popularity	Predict the number of times articles were shared on social networks.	27,750	60
  NYC Taxi	Predict the tip amount for a New York City taxicab.	407,284	15
  Twitter	The popularity of a topic on social media.	408,275	78

• For each dataset, use 70% of the data for training and 30% of the data for testing. We recommend randomly selecting training data from the data set.
• Compute balanced accuracy for classification and R2 regression for regression on the test set.

2. HeatWave AutoML specific setup

• Use a HeatWave cluster with two HeatWave nodes.
• Run ML_TRAIN with the default arguments, and set task to classification or regression based on the dataset type.
• Score the generated model using ML_SCORE, with the metric set to balanced_accuracy for classification and R2 for regression.

3. Amazon Redshift ML specific setup

• Use a Redshift cluster with two nodes on ra3.4xlarge shape.
• Run CREATE_MODEL with the default values of MAX_CELLS (1M) and MAX_RUNTIME (5400s).
  • For classification dataset, do not specify problem_type and let SageMaker detect the problem type.
  • For regression dataset, run CREATE_MODEL with PROBLEM_TYPE being REGRESSION.
• Create custom SQL scoring functions to calculate balanced accuracy for classification and R2 for regression.

4. Setup for scalability test

• Test with 2, 4, 8, and 16 HeatWave node cluster.
• Run ML_TRAIN on all datasets described in common setup section.
• Compute HeatWave AutoML versus Redshift ML speedup for training on every dataset via the following:
  • (Redshift ML default training time budget (90 minutes)) / (HeatWave AutoML end-to-end ML_TRAIN time)
• Compute geometric mean of speedup across the datasets for each of the cluster configurations.
• Once all five geometric mean speedup values are obtained, plot geomean speedup (y-axis) versus cluster size (x-axis).

5. Results

Performance comparison of HeatWave MySQL on AWS with Amazon Aurora, Amazon Redshift, Snowflake, Azure Synapse Analytics, and Google BigQuery

Several performance comparisons have been run and the results are presented below. They focus on two different aspects.

• OLAP performance
  The performance comparison includes the TPC-H benchmark* with a dataset of 4 TB, to validate the speedup provided by HeatWave MySQL on AWS.
• OLTP performance
  The performance comparison includes the TPC-C benchmark** with a dataset of 10 GB to validate the throughput provided by HeatWave MySQL on AWS.

1. Common setup for analytic (OLAP) workload test for TPC-H

• The workload is derived from TPC's TPC-H benchmarks.*
• Generate data using the corresponding data generation tool.
• Provision and configure the target service.
• Create the corresponding schema on the target service instance.
• Import the data generated to the target service instance.
• Run queries derived from TPC-H to test the performance.
• For best performance numbers, always do multiple runs of the query and ignore the first (cold) run.
• You can always do an explain plan to make sure you get the best expected plan.

2. Common setup for transactional (OLTP) workload test for TPC-C

• The workload is derived from the TPC-C benchmark.**
• The sysbench framework (with additional Lua scripts for TPC-C) is used to run the TPC-C benchmark.
• Provision and configure the target service instance.
• Create the OLTP workload schema (TPC-C) on the target service instance.
• Generate and load the 100 W (10 GB) dataset to the target service instance.
• Start with one concurrent session and gradually increase the number of concurrent sessions to see the impact on throughput and latency.
• Note the OLTP throughput as reported.

3. HeatWave specific setup

• The MySQL.32.256GB shape is used for the MySQL node and the HeatWave.256GB shape is used for the HeatWave nodes.
• For TPC-H benchmark
  • Optimal encodings are used for certain columns that will be loaded into HeatWave.
  • Custom data placement is used for certain tables that will be loaded into HeatWave.
  • Mark the tables as offloadable and load them into HeatWave.
  • For each query, force offload to HeatWave using the hint (set_var(use_secondary_engine=forced)).
  • A straight_join hint is required for certain queries to get the optimal query plan for HeatWave.
• For TPC-C benchmark
  • Make sure the client and HeatWave instance are in the same physical AZ.
• For a detailed setup, reference the following:
  • HeatWave TPC-H GitHub for TPC-H.
  • HeatWave GitHub for TPC-C benchmark.

4. Snowflake on AWS specific setup

• In the experiments, a medium-size cluster is used.
• For TPC-H, use clustering on ORDERS(o_orderdate) and LINEITEM(l_shipdate) tables.
• You can also try without clustering and pick the scheme that gives better performance.

5. Amazon Redshift specific setup

• Determine the best shape and cluster size for the experiments. In the experiments, two nodes of ra3.4xlarge instance shape were used.
• For efficient data ingestion, follow the guidelines for enhanced VPC routing.
• Use the default parameters as specified by the Amazon documentation.
• Make sure the sort keys and distribution keys for each table are optimal for queries. The scripts provided by awslabs can be used for reference.

6. Microsoft Azure Synapse specific setup

• In the experiments, DW 1500c cluster is used.

7. Google BigQuery specific setup

• In the experiments, 400 slots are used for running the queries.

8. Amazon Aurora specific setup for TPC-C benchmark

• Use the db.r5.8xlarge shape.
• Use the default parameter settings for innodb_buffer_pool and other parameters.
• Set adaptive hash index = off; replication = off; redo_log = off.
• Follow the best practices for Aurora database configuration for any other tuning.

9. Results

Performance comparison of HeatWave Lakehouse with Snowflake, Amazon Redshift, Google BigQuery, and Databricks

Performance comparisons for a very large data set were run, and the results are presented below. The results focus on both load and query performance.

The content below details the setup for the TPC-H analytic workload for a scale factor of 500,000 (a data set size of 500 TB) and the TPC-DS analytic workload with a data set size of 100 TB.

1. Common setup for analytic workload test for TPC-H and TPC-DS

The workload is derived from the TPC's TPC-H and TPC-DS benchmarks.^*

• Generate data using the corresponding data generation tool.
• Keep the generated data in a bucket in the respective cloud service (Oracle Cloud Infrastructure, Amazon Web Services, or Google Cloud Platform). Ensure the bucket is in the same region where the database system will be provisioned.
• Provision and configure the target service.
• Create the corresponding schema on the target service instance.
• Load the data generated to the target service instance and measure the load time.
• Run queries derived from TPC-H or TPC-DS to test the performance.
• For best performance numbers, always do multiple runs of the query and ignore the first (cold) run.
• You can always run an explain plan to make sure you get the best expected plan.

2. HeatWave Lakehouse specific setup

• For TPC-H, a 512-node HeatWave cluster is used for the experiments.
• For TPC-DS, a 120-node HeatWave cluster is used for the experiments.
• Custom data placement is used for certain tables that will be loaded into HeatWave Lakehouse.
• Mark the tables as offloadable and load them into HeatWave.

• For a detailed setup, reference the following:

  • HeatWave TPC-H GitHub for TPC-H
  • HeatWave TPC-DS GitHub for TPC-DS

3. Snowflake on AWS specific setup

• For TPC-H, use clustering on ORDERS(o_orderdate) and LINEITEM(l_shipdate) tables.
• You can also try without clustering and pick the scheme that gives better performance.

• Determine the best cluster size for the experiments.

  • For 500 TB TPC-H, a 4X-Large cluster is used.
  • For 100 TB TPC-DS, a 3X-Large cluster is used.

4. Amazon Redshift specific setup

• Determine the best shape and cluster size for the experiments.

  • For 500 TB TPC-H, 20 nodes of a ra3.16xlarge instance are used in these experiments.
  • For 100 TB TPC-DS, 10 nodes of a ra3.16xlarge instance are used.
• For efficient data ingestion, follow the guidelines for enhanced VPC routing.
• Use the default parameters as specified by the Amazon documentation.
• Make sure the sort keys and distribution keys for each table are optimal for queries.

5. Google BigQuery specific setup

• Determine the ideal number of slots for the experiments.

  • For 500 TB TPC-H, 6,400 slots are used.
  • For 100 TB TPC-DS, 3,200 slots are used.

6. Databricks on AWS specific setup

• Determine the ideal cluster size for the experiments.

  • For 500 TB TPC-H, a 3X-Large cluster is used.
  • For 100 TB TPC-DS, a 2X-Large cluster is used.

7. Results

Notes:

1. Redshift pricing is based on one-year reserved instance pricing (paid all upfront).
2. Snowflake pricing is based on standard edition on-demand pricing.
3. Google BigQuery pricing is based on annual flat-rate commitment (per 100 slots).
4. Databricks Enterprise Sql Pro pricing is based on one-year reserved EC2 instance.

100 TB TPC-DS—concurrent users

HeatWave concurrent execution is better than other services

TPC-DS 100TB

	HeatWave	Snowflake	Redshift	BigQuery	Databricks
1 client price-performance	1X	3.3X	2.1X	4.2X	6.8X
2 clients price-performance	1X	3.4X	1.8X	4.1X	6.8X
4 clients price-performance	1X	2.9X	1.6X	3.5X	5.3X
8 clients price-performance	1X	5X	2X	3.4X	5.4X

Note: Snowflake, Redshift, Google BigQuery, and Databricks numbers for 500 TB TPC-H and 100 TB TPC-DS are provided by a third party.

^*Benchmark queries are derived from TPC-H and TPC-DS benchmarks, but results aren’t comparable to published TPC-H and TPC-DS benchmark results since these don’t comply with the TPC-H and TPC-DS specifications.

Performance comparisons of HeatWave GenAI with Snowflake, Databricks, and Google BigQuery

Performance comparisons for a variety of queries on data sets of different sizes were done, and the results are presented below.

The content below details the setup for three data sets: Wikipedia (1.7 GB), dbpedia (3 GB), and MIRACL (300 GB).

Common setup

Download the data sets required for the queries.

• Wikipedia
• dbpedia
• MIRACL_en
• MIRACL_de
• msmacro

Once the data is downloaded

1. Provision and configure the target service.
2. Create the corresponding schema on the target service instance.
3. Import the data to the target service instance.
4. Run the queries to test the performance.
5. The queries are a mix of queries that do nearest neighbor top 10 results (in ascending and descending order) with different distance metrics, do nearest neighbor queries with additional predicates, do joins between tables with different languages, do semantic searches on the joined result, use embedding column as an aggregation result, do distance-based filtering, and so forth.
6. For best performance numbers, always do multiple runs of the query and ignore the first (cold) run.

Results

Notes

1. All costs only include the compute cost. Storage costs aren’t included.
2. Snowflake pricing is based on standard edition on-demand pricing.
3. Google BigQuery pricing is based on standard edition pay-as-you-go pricing.
4. Databricks pricing is based on a premium SQL serverless compute 2X-small shape, plus the cost of Mosaic vector search.

Vector search results

Note: All numbers were provided by a third party in June 2024.

Performance comparisons of HeatWave Vector Store on AWS with Knowledge Bases for Amazon Bedrock

Performance comparisons for creating a vector store using a variety of documents were completed and the results are presented below.

Data set used
100K files from Wikipedia, converted into different formats.

Setup

1. Upload the documents into the Amazon S3 bucket.
2. Provision and configure HeatWave on AWS as well as Knowledge Bases for Amazon Bedrock.
3. Trigger vector store creation from the uploaded documents.

Results

Notes

1. All costs only include the compute cost. Storage costs aren’t included.
2. The vector store creation cost for HeatWave is based on the following configuration: one MySQL node with 2 vCPUs and 10 HeatWave cluster nodes.
3. The vector store creation for Knowledge Bases for Amazon Bedrock includes naming the knowledge base, configuring the data source in S3, using Cohere Embed English v3 for embedding, followed by “quick create of vector store.” The costs considered in the comparative measurements for embedding the ingested documents were recorded from the AWS bill and then discounted by 50% for batch discount.