Snowflake Query Acceleration Service 101: Speed Up Queries (2025)

Snowflake Query Acceleration Service (QAS)—exclusively available for Enterprise Edition or above—is a powerful serverless service that can dramatically improve the performance of your Snowflake warehouse. Snowflake Query Acceleration Service (QAS) works by offloading parts of the query workload to shared compute resources, which can significantly reduce the impact of resource-hungry outlier queries. This, in turn, leads to order-of-magnitude performance gains for queries that scan large data volumes or have complex filters.

In this article, we will provide an in-depth overview of Snowflake query acceleration service, explain how it works to improve Snowflake warehouse performance, detail the types of workloads that benefit most, and provide step-by-step guide on enabling, monitoring, and using this feature.

What is Snowflake Query Acceleration Service?

Snowflake Query Acceleration Service (QAS) is a serverless feature that can be enabled for any Snowflake Virtual Warehouse. Its purpose is to enhance query performance by automatically allocating additional serverless compute resources to accelerate portions of query processing, particularly for large table scans and selective filtering operations. The query acceleration service can handle these types of workloads more efficiently by performing more work in parallel and reducing the wall-clock time spent in scanning and filtering.

How does Snowflake Query Acceleration Service work

Whenever you execute a query in Snowflake, it first checks if there are sufficient resources available to process it. If the warehouse is already too busy, the query gets queued and put on hold. This can be a problem when running workloads that include both short and long-running queries. Long-running queries can also hinder the execution of other queries. While upgrading to a larger Snowflake warehouse might seem like a viable solution, it is not optimal since smaller queries do not fully utilize the available resources, leading to increased query costs.

The Snowflake Query Acceleration Service (QAS) provides additional serverless compute resources that can be temporarily utilized alongside your existing warehouse. When Snowflake detects an eligible query that would benefit from acceleration, it offloads portions of the query processing work to shared compute resources provided by the service. This reduces the demand on the warehouse's compute resources while speeding up query execution. Snowflake Query Acceleration Service resources are billed based on actual usage (per-second billing), ensuring that you only pay for the compute resources utilized when queries are being accelerated.

Snowflake Query Acceleration Service (QAS) can benefit a wide variety of workloads, including:

• Ad hoc analytics
• Workloads with unpredictable data volume per query
• Queries with large scans and selective filters

Source: Snowflake Documentation

Snowflake Query Acceleration Service can help to improve performance for these types of workloads by offloading portions of the query processing work to shared compute resources that are provided by the service. This can help to reduce the wall-clock time spent in scanning and filtering, which can lead to significant improvements in overall Snowflake query performance.

Important Note: The query acceleration service depends on server availability. Performance improvements can vary for the same query executed at different times based on resource availability. Snowflake automatically determines whether to use QAS on a query-by-query basis.

TLDR;

As you can see in the illustration, a small warehouse equipped with a Query Acceleration System (QAS) has the capability to scale up by a factor of 8X. Upon detecting a substantial query, the QAS allocates additional resources, enabling quicker performance.

Now, before we dive into the implementation of the Snowflake Query Acceleration Service, it is essential to understand which types of queries and warehouses are eligible for this service.

What types of queries and warehouses are eligible for Snowflake Query Acceleration Service (QAS)?

Snowflake Query Acceleration Service (QAS) is activated at the warehouse level, yet not all queries are eligible to leverage it. As of now, Snowflake QAS supports the following types of queries:

• SELECT
• INSERT (including INSERT with SELECT statements)
• CREATE TABLE AS SELECT (CTAS)
• COPY (COPY INTO statements that involve large scans)

These queries are eligible when they have a portion of the query plan that can be run in parallel using QAS compute resources. In general, eligible queries fall into one of two patterns:

1. Large scans with an aggregation or selective filter
2. Large scans that insert or copy many new rows

Keep in mind that the Snowflake Query Acceleration Service is designed to assist when a warehouse has outlier queries. If the warehouse is not processing queries that would benefit from additional compute resources, QAS will not activate.

Certain queries fall outside the eligibility bracket for Snowflake Query Acceleration Service due to various reasons, such as:

• Not having enough partitions to scan (insufficient partitions to benefit from parallelization)
• Having filters that are not selective enough to benefit from acceleration
• Having a GROUP BY clause with cardinality that is too high for eligibility
• Having a LIMIT clause that prevents acceleration (Note: QAS now automatically determines which queries with LIMIT clauses—including those without ORDER BY—can be accelerated, but some LIMIT queries may still be ineligible)
• Including functions that return non-deterministic results (e.g., SEQ, RANDOM)

Note: Snowflake doesn't have a specific cutoff for what constitutes a "large enough" scan to be eligible. The threshold for eligibility depends on various factors, including the query plan and warehouse size. Snowflake only marks a query as eligible if there is high confidence that the query would be accelerated if QAS was enabled.

To check whether queries are eligible for Query Acceleration and if they will benefit from enabling it, use the following methods.

Check eligibility using:

1) SYSTEM$ESTIMATE_QUERY_ACCELERATION function

This built-in Snowflake function can be used to determine if a query is eligible for Snowflake Query Acceleration Service. The function returns a JSON object with the following information:

• originalQueryTime: The estimated execution time of the query without Snowflake Query Acceleration service enabled (original query).
• upperLimitScaleFactor: The maximum scale factor that can be used for the query.
• queryUUID: Query ID.
• Status: The status of the query, which can be either eligible or ineligible.
• estimatedQueryTimes: A map of scale factors to estimated execution times.

The following example shows how to use the SYSTEM$ESTIMATE_QUERY_ACCELERATION function to check the eligibility of a query:

select parse_json(system$estimate_query_acceleration('<query_id>'));

If the query is ineligible for Snowflake Query Acceleration service, the status will be ineligible and the upperLimitScaleFactor will be 0. The estimatedQueryExecutionTime field will be null.

For example,

{
  "status": "ineligible",
  "upperLimitScaleFactor": 0,
  "estimatedQueryExecutionTime": null
}

And, if the query is eligible for Snowflake Query Acceleration service, the function will return a status of eligible and the upperLimitScaleFactor will be a positive integer. The estimatedQueryExecutionTime field will include the estimated query execution time for various scale factors.

For example,

{
  "status": "eligible",
  "upperLimitScaleFactor": 10,
  "estimatedQueryExecutionTime": {
    "1": 100 seconds,
    "2": 50 seconds,
    "3": 33.33 seconds,
    "4": 25 seconds,
    "5": 20 seconds,
    "6": 16.67 seconds,
    "7": 14.28 seconds,
    "8": 12.5 seconds,
    "9": 11.11 seconds,
    "10": 10 seconds
  }
}

2) QUERY_ACCELERATION_ELIGIBLE view

The QUERY_ACCELERATION_ELIGIBLE view identifies the queries and warehouses that might benefit the most from the Snowflake query acceleration service. Important: This view only includes eligible queries that have not been accelerated. If you have enabled the query acceleration service and previously QAS-eligible queries are now accelerated, they are not included in this view. Additionally, there may be up to 180 minutes (three hours) of latency for this view.

The following examples assume the usage of the ACCOUNTADMIN role or a role granted IMPORTED PRIVILEGES on the shared SNOWFLAKE database. If these roles are not in use, execute the following command before running the queries:

USE ROLE ACCOUNTADMIN;

To identify the queries that can benefit the most from the service based on the amount of eligible query execution time, execute the following query:

SELECT query_id, eligible_query_acceleration_time
  FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_ACCELERATION_ELIGIBLE
  ORDER BY eligible_query_acceleration_time DESC;

Since Snowflake query acceleration service operates at the warehouse level, it is helpful to determine which warehouses have the highest acceleration opportunities.

This query identifies the warehouses with the most queries eligible for the query acceleration service within a given period:

SELECT warehouse_name, COUNT(query_id) AS num_eligible_queries
  FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_ACCELERATION_ELIGIBLE
  WHERE start_time > 'Mon, 29 May 2023 00:00:00'::timestamp
  AND end_time < 'Tue, 30 May 2023 00:00:00'::timestamp
  GROUP BY warehouse_name
  ORDER BY num_eligible_queries DESC;

To identify the warehouses with the most eligible time for the query acceleration service, execute the following query:

SELECT warehouse_name, SUM(eligible_query_acceleration_time) AS total_eligible_time
  FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_ACCELERATION_ELIGIBLE
  GROUP BY warehouse_name
  ORDER BY total_eligible_time DESC;

Check out the Snowflake documentation for more!

Before we dive into how to enable Snowflake's Query Acceleration services, let's first understand what Scale Factor is and how it works in QAS.

What is Scale Factor and how it works in Snowflake Query Acceleration (QAS)?

Scale Factor is a cost control mechanism that sets an upper bound limit on the amount of compute resources that a virtual warehouse can use for query acceleration. It acts as a multiplier based on the size and hourly credit cost of the warehouse.

The Scale Factor sets the maximum capacity, but the actual QAS resources used will vary based on factors like query eligibility, data processed, and resource availability. The query acceleration service only uses as many resources as it needs and that are available at the time the query is executed. QAS is billed by the second, only when in use.

If the scale factor is not explicitly set, the default value is 8. A value of 0 (Scale factor) eliminates the upper limit and allows QAS to lease as many resources as necessary and as available to accelerate the Snowflake query.

Note: Not all queries require the full set of resources that are made available by the scale factor. The amount of resources requested depends on how much of the query is eligible for acceleration and how much data will be processed. Regardless of the scale factor value or the amount of resources requested, the available compute resources for query acceleration are bound by the availability of resources in the service and the number of other concurrent requests.

Enabling Snowflake Query Acceleration Service

To enable the Snowflake Query Acceleration Service (QAS) in Snowflake, you can use the following steps:

Step1—Enabling Query Acceleration Service during Snowflake warehouse creation:

-- Upon warehouse creation
CREATE WAREHOUSE my_wh
  ENABLE_QUERY_ACCELERATION = true;

This will create a Snowflake warehouse named my_warehouse with Snowflake Query Acceleration Service enabled.

Step2—Enabling Query Acceleration Service on an existing Snowflake warehouse:

-- Enable on an existing warehouse
ALTER WAREHOUSE COMPUTE_WH
  SET ENABLE_QUERY_ACCELERATION = true;

This enables Query Acceleration Service for the existing Snowflake warehouse named my_warehouse.

When using Snowflake Query acceleration service, it's important to consider the cost implications. Snowflake Query acceleration service can increase costs depending on the amount of resources leased by the warehouse.

To control the resource allocation, you can set the maximum scale factor using the QUERY_ACCELERATION_MAX_SCALE_FACTOR warehouse parameter. This parameter determines the multiplier of the current Snowflake warehouse size for leasing compute resources.

To illustrate the scaling capabilities of Snowflake's Query Acceleration Service (QAS), let's consider an example scenario. Suppose let's consider you setup the scale factor to 4 for a medium warehouse.

ALTER WAREHOUSE COMPUTE_WH
  SET ENABLE_QUERY_ACCELERATION = true,
      QUERY_ACCELERATION_MAX_SCALE_FACTOR = 4;

Here's how it would work:

The scale factor determines the maximum compute resources that can be allocated for query acceleration. In this case, the warehouse can lease compute resources up to 4 times the credit consumption rate of a medium warehouse.

Since a medium Snowflake warehouse costs 4 credits per hour, setting the scale factor to 4 means the query acceleration service can cost up to an additional 16 credits per hour (4 credits per warehouse × 4 scale factor = 16 additional credits per hour maximum). However, QAS only consumes credits when actively accelerating queries, and may use less than the maximum depending on query needs.

Note: The scale factor applies to the entire warehouse, whether it's a single-cluster or multi-cluster warehouse. If you use QAS for a multi-cluster warehouse, consider increasing the scale factor so that all the warehouse clusters can take advantage of the QAS optimizations.

You can also set the scale factor to 0, which gives Snowflake complete freedom to dynamically scale up Snowflake Query acceleration service based on the query's requirements. This approach provides even greater flexibility in handling queries of any size, allowing Snowflake to allocate resources as needed to optimize query execution.

Monitoring Snowflake query acceleration service

To monitor the usage of Snowflake query acceleration service, you can use the following options:

1) QUERY_HISTORY view:

This view provides information about the queries that have benefited from query acceleration.

It includes the following columns:

• QUERY_ACCELERATION_BYTES_SCANNED: The number of bytes scanned by the query acceleration service.
• QUERY_ACCELERATION_PARTITIONS_SCANNED: The number of partitions scanned by the query acceleration service.
• QUERY_ACCELERATION_UPPER_LIMIT_SCALE_FACTOR: The maximum scale factor that was used for the query.

2) QUERY_ACCELERATION_HISTORY view:

This view provides information about the warehouse-level credit consumption for query acceleration. You can use this view to track the additional cost per Snowflake warehouse for using Snowflake query acceleration service.

The QUERY_ACCELERATION_HISTORY view provides the following columns:

• START_TIME: The start time of the query acceleration session
• END_TIME: The end time of the query acceleration session
• CREDITS_USED: The number of credits used for the query acceleration session
• WAREHOUSE_ID: The ID of the Snowflake warehouse where the query acceleration session occurred
• WAREHOUSE_NAME: The name of the Snowflake warehouse where the query acceleration session occurred
• NUM_FILES_SCANNED: The number of files scanned during query acceleration
• NUM_BYTES_SCANNED: The number of bytes scanned during query acceleration

Here is an example of a query that you can use to get the Snowflake query acceleration service cost, credits usage, bytes scanned—and more for each Snowflake warehouse :

SELECT
  START_TIME,
  END_TIME,
  CREDITS_USED,
  WAREHOUSE_NAME,
  NUM_FILES_SCANNED,
  NUM_BYTES_SCANNED
FROM
  TABLE(INFORMATION_SCHEMA.QUERY_ACCELERATION_HISTORY())
ORDER BY
  START_TIME DESC;

3) Using Chaos Genius to monitor Snowflake Query Acceleration:

Chaos Genius's advanced Snowflake Cost Explorer allows you to effectively monitor and optimize the Snowflake Query Acceleration Service (QAS). With the help of Chaos Genius, you can:

• Get detailed insights into the costs associated with Snowflake Query Acceleration Service (QAS).
• Identify the factors driving costs for Snowflake Query Acceleration Service QAS.
• Make informed decisions regarding resource allocation and spending for QAS.

Chaos Genius helps monitor and optimize Snowflake Query Acceleration Service (QAS) in the following ways:

• Monitoring QAS costs: Chaos Genius can track the costs incurred by Snowflake QAS usage. It provides detailed costs broken down into simpler manner, which helps gain visibility into how much is being spent on QAS and identify any cost spikes.
• Tracking QAS usage by warehouse: Chaos Genius provide detailed breakdown on which Snowflake warehouses have QAS enabled. This helps to make sure that QAS is enabled only in warehouses where it is useful and providing performance benefits. QAS can be disabled on warehouses where it is not needed to optimize costs.
• Recommendations on enabling/disabling QAS: Based on the query load and performance metrics for Snowflake, Chaos Genius can determine if QAS will help accelerate queries on that warehouse or not. It can then provide recommendations to enable or disable QAS for optimal cost and performance.

Best Practices for Snowflake Query Acceleration Service

Implementing Snowflake Query Acceleration Service effectively requires careful planning, monitoring, and optimization. Here in this section we will provide a comprehensive best practices to help you maximize the benefits of QAS while managing costs effectively.

1) Figure Out When to Enable Qas and When Not To

Query Acceleration Service provides the most value in specific scenarios where traditional warehouse scaling is inefficient or cost-prohibitive:

• Unpredictable Ad Hoc Workloads: When users run exploratory queries with varying data volumes that are difficult to predict in advance. QAS allows you to maintain a smaller baseline warehouse while handling occasional resource-intensive queries automatically.
• Mixed Workload Environments: When a single warehouse processes both lightweight queries (completing in seconds) and heavy analytical queries (requiring minutes). QAS prevents long-running queries from blocking other queries by offloading intensive operations to serverless resources.
• Outlier Query Management: When most queries run efficiently, but a small percentage of queries consume disproportionate resources. QAS specifically targets these outlier queries, improving overall warehouse throughput without requiring permanent warehouse size increases.
• Large Scan Operations with Selective Filters: Queries that scan billions of rows but return a small subset based on selective filtering conditions benefit significantly from QAS's parallel processing capabilities.

When NOT to Enable QAS:

Understanding when QAS is not appropriate is equally important for cost optimization:

• Small Tables or Low Data Volumes: QAS requires sufficient partitions to parallelize work effectively. Tables under 1TB rarely benefit from QAS, and enabling it may add unnecessary overhead and cost.
• Consistently Heavy Workloads: If all or most queries in a warehouse are resource-intensive, permanently scaling up the warehouse size is more cost-effective than using QAS. QAS is designed for occasional bursts, not sustained heavy loads.
• Highly Optimized Queries: If queries are already well-optimized with proper clustering, partition pruning, and efficient SQL patterns, they may not be eligible for QAS or may see minimal improvement.
• Cost-Sensitive Small Deployments: For small teams with limited budgets, the additional serverless compute costs may outweigh the performance benefits, especially if warehouse utilization is already efficient.
• Tables with Frequent DML Operations: Tables with many INSERT, UPDATE, MERGE, or DELETE operations may not benefit from QAS and could incur costs without performance gains.

2) Optimize Scale Factor Settings

The scale factor is your primary cost control mechanism for QAS. Choosing the right value requires balancing performance needs against budget constraints.

Scale Factor Strategy:

Start Conservative and Scale Up: Begin with a low scale factor (4 or lower) and gradually increase it based on actual performance gains and cost impact. Lower scale factors are more likely to provide cost-neutral benefits.

Recommended Starting Values:

• Small to Medium Warehouses: Start with scale factor 3-4
• Large to X-Large Warehouses: Start with scale factor 6-8
• Testing/Development: Consider scale factor 2 to minimize costs
• Performance-Critical Production: May use scale factor 0 (unlimited) for critical workloads where performance is paramount

3) Monitoring Thoroughly

Effective monitoring is essential to ensure QAS delivers value without unexpected cost overruns.

Key Monitoring Queries:

Monitor QAS Credit Consumption by Warehouse:

SELECT
  WAREHOUSE_NAME,
  DATE_TRUNC('day', START_TIME) AS usage_date,
  SUM(CREDITS_USED) AS total_qas_credits,
  SUM(NUM_FILES_SCANNED) AS files_scanned,
  SUM(NUM_BYTES_SCANNED) AS bytes_scanned,
  COUNT(*) AS qas_executions
FROM TABLE(INFORMATION_SCHEMA.QUERY_ACCELERATION_HISTORY(
  DATE_RANGE_START => DATEADD('day', -30, CURRENT_TIMESTAMP())
))
GROUP BY WAREHOUSE_NAME, DATE_TRUNC('day', START_TIME)
ORDER BY total_qas_credits DESC;

Compare QAS Costs vs. Normal Warehouse Costs:

Snowflake recommends comparing eight weeks before enabling QAS with eight weeks after to assess cost impact:

WITH qas_costs AS (
  SELECT
    WAREHOUSE_NAME,
    DATE_TRUNC('week', START_TIME) AS week,
    SUM(CREDITS_USED) AS qas_credits
  FROM TABLE(INFORMATION_SCHEMA.QUERY_ACCELERATION_HISTORY())
  WHERE START_TIME >= DATEADD('week', -16, CURRENT_TIMESTAMP())
  GROUP BY WAREHOUSE_NAME, DATE_TRUNC('week', START_TIME)
),
warehouse_costs AS (
  SELECT
    WAREHOUSE_NAME,
    DATE_TRUNC('week', START_TIME) AS week,
    SUM(CREDITS_USED) AS warehouse_credits
  FROM SNOWFLAKE.ACCOUNT_USAGE.WAREHOUSE_METERING_HISTORY
  WHERE START_TIME >= DATEADD('week', -16, CURRENT_TIMESTAMP())
  GROUP BY WAREHOUSE_NAME, DATE_TRUNC('week', START_TIME)
)
SELECT
  COALESCE(q.WAREHOUSE_NAME, w.WAREHOUSE_NAME) AS warehouse,
  COALESCE(q.week, w.week) AS week,
  COALESCE(w.warehouse_credits, 0) AS warehouse_credits,
  COALESCE(q.qas_credits, 0) AS qas_credits,
  COALESCE(w.warehouse_credits, 0) + COALESCE(q.qas_credits, 0) AS total_credits,
  AVG(COALESCE(w.warehouse_credits, 0) + COALESCE(q.qas_credits, 0)) 
    OVER (PARTITION BY COALESCE(q.WAREHOUSE_NAME, w.WAREHOUSE_NAME) 
          ORDER BY COALESCE(q.week, w.week) 
          ROWS BETWEEN 6 PRECEDING AND CURRENT ROW) AS seven_day_avg
FROM qas_costs q
FULL OUTER JOIN warehouse_costs w
  ON q.WAREHOUSE_NAME = w.WAREHOUSE_NAME AND q.week = w.week
ORDER BY warehouse, week;

Identify Queries Benefiting Most from QAS:

SELECT
  q.QUERY_ID,
  q.QUERY_TEXT,
  q.WAREHOUSE_NAME,
  q.TOTAL_ELAPSED_TIME / 1000 AS elapsed_seconds,
  q.BYTES_SCANNED,
  q.QUERY_ACCELERATION_BYTES_SCANNED,
  q.QUERY_ACCELERATION_PARTITIONS_SCANNED,
  q.QUERY_ACCELERATION_UPPER_LIMIT_SCALE_FACTOR,
  ROUND(q.QUERY_ACCELERATION_BYTES_SCANNED::FLOAT / NULLIF(q.BYTES_SCANNED, 0) * 100, 2) 
    AS pct_bytes_accelerated
FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY q
WHERE q.START_TIME >= DATEADD('day', -7, CURRENT_TIMESTAMP())
  AND q.QUERY_ACCELERATION_BYTES_SCANNED > 0
ORDER BY q.QUERY_ACCELERATION_BYTES_SCANNED DESC
LIMIT 100;

Set Up Resource Monitors:

Configure resource monitors to prevent unexpected cost spikes:

CREATE RESOURCE MONITOR qas_warehouse_monitor
  WITH CREDIT_QUOTA = 1000
  TRIGGERS
    ON 80 PERCENT DO NOTIFY
    ON 100 PERCENT DO SUSPEND;

ALTER WAREHOUSE COMPUTE_WH SET RESOURCE_MONITOR = qas_warehouse_monitor;

4) Combine QAS with Other Snowflake Features

Query Acceleration Service works synergistically with other Snowflake performance optimization features.

QAS + Search Optimization Service (SOS):

Query acceleration and Search Optimization Service can work together to optimize query performance. First, Search Optimization Service can prune the micro-partitions not needed for a query. Then, for eligible queries, query acceleration can offload portions of the rest of the work to shared compute resources provided by the service.

• Enable SOS on tables with highly selective lookup queries (finding specific rows in billions of records)
• Enable QAS on the warehouse to accelerate queries that scan large datasets with aggregations or filters
• Together, SOS reduces the data that needs scanning, while QAS accelerates the processing of the remaining data in parallel

QAS + Automatic Clustering:

Clustering improves partition pruning by physically sorting data, which complements QAS:

• Well-clustered tables allow Snowflake to skip irrelevant partitions early
• QAS then accelerates the scanning and filtering of the remaining relevant partitions
• This combination is particularly effective for large fact tables with time-based queries

QAS + Materialized Views:

For frequently executed aggregations, materialized views can eliminate the need for QAS:

• Evaluate whether creating a materialized view is more cost-effective than repeatedly using QAS
• Use materialized views for predictable, repetitive aggregations
• Use QAS for unpredictable, ad hoc analytical queries that cannot be pre-aggregated

5) Auto-Suspend and QAS Interaction

To maximize the amount of time your warehouse is able to shut down after completing QAS-accelerated queries, ensure that you have auto-suspend enabled on your warehouse. This prevents warehouses from remaining active unnecessarily after QAS completes query acceleration.

Recommended Auto-Suspend Settings with QAS:

ALTER WAREHOUSE COMPUTE_WH
  SET ENABLE_QUERY_ACCELERATION = TRUE,
      QUERY_ACCELERATION_MAX_SCALE_FACTOR = 4,
      AUTO_SUSPEND = 60,
      AUTO_RESUME = TRUE;

Setting auto-suspend to 60 seconds is optimal because Snowflake bills for a minimum of 60 seconds when a warehouse resumes. Lower values can result in double-charging without additional benefit.

Common Pitfalls of QAS to Avoid

1) Enabling QAS on All Warehouses Indiscriminately

Not all warehouses benefit from QAS. Target specific warehouses with eligible queries and outlier patterns.

2) Setting Scale Factor Too High Initially

There can be a logarithmic relationship between scale factor and query time reduction. Doubling the scale factor does not double performance gains but does double maximum cost.

3) Ignoring the QUERY_ACCELERATION_ELIGIBLE View

QUERY_ACCELERATION_ELIGIBLE view only includes eligible queries that have not been accelerated. If QAS is already enabled and working, previously eligible queries won't appear in this view. There may also be up to 180 minutes of latency for this view.

4) Not Monitoring Actual vs. Maximum Cost

Just because you set a scale factor of 8 doesn't mean you'll always use 8x additional compute. Monitor actual usage to understand true cost impact.

5) Overlooking Query Optimization

QAS is not a substitute for proper query optimization. Always optimize SQL queries, use appropriate clustering, and leverage caching before relying on QAS.

6) Forgetting About Bytes Spilled to Remote Storage

When QAS is enabled, Snowflake writes a small amount of data to remote storage for each eligible query, even if QAS isn't used for that query. Don't be concerned by nonzero bytes_spilled_to_remote_storage values in QUERY_HISTORY when QAS is enabled.

Conclusion

In a nutshell, Snowflake Query Acceleration Service (QAS) is like a turbocharger for your SQL queries. It dynamically allocates extra compute power to tackle large table scans, boosting Snowflake query performance without breaking the bank. Ideal for mixed workloads, QAS ensures efficient resource usage and faster query execution.

In this article, we have covered:

• What Is Snowflake Query Acceleration Service?
• Snowflake Query Acceleration Service Architecture
• Types of Queries and Warehouses Eligible for Snowflake Query Acceleration Service
• Step-Bystep Guide to Enable Snowflake Query Acceleration Service
• Guide to Monitor Snowflake Query Acceleration Service
• Best Practices for Snowflake Query Acceleration Service

... and so much more!.

FAQs

What is Snowflake Query Acceleration Service (QAS)?

Snowflake Query Acceleration Service (QAS) accelerates query performance by offloading compute-intensive work to dedicated Snowflake servers. It's ideal for queries that scan large datasets.

How does Snowflake Query Acceleration Service (QAS) work?

Snowflake Query Acceleration Service (QAS) automatically detects eligible queries then allocates extra resources to accelerate data scanning and filtering.

What are the benefits of using Snowflake Query Acceleration Service (QAS)?

• Snowflake Query Acceleration Service (QAS) can significantly improve the Snowflake query performance, especially for queries that scan large amounts of data.
• Snowflake Query Acceleration Service (QAS) is a pay-as-you-go feature, so you only pay for the resources that you use. This can help you to reduce your Snowflake costs.
• Snowflake Query Acceleration Service (QAS) can be used to accelerate a wide variety of queries, including ad hoc queries, batch queries, and analytical queries. This gives you more flexibility in how you use Snowflake.

How do I enable Snowflake Query Acceleration Service (QAS) ?

To enable Snowflake Query Acceleration Service (QAS), you first need to do the following:

CREATE WAREHOUSE my_warehouse
ENABLE_QUERY_ACCELERATION = TRUE;

Or, if you already have a warehouse created, you can enable QAS by using the ALTER WAREHOUSE statement:

ALTER WAREHOUSE my_warehouse
ENABLE_QUERY_ACCELERATION = TRUE;

Once Snowflake Query Acceleration Service (QAS) is enabled, it will be automatically used to accelerate eligible queries.

What are the limitations of Snowflake Query Acceleration Service (QAS)?

• Doesn't accelerate queries that don't scan data
• Can't accelerate ineligible queries
• Adds minor overhead

Is Snowflake Query Acceleration Service (QAS) right for me?

Yes, Snowflake Query Acceleration Service (QAS) is a great option for users who want to improve the performance and reduce the costs of their Snowflake queries. If you are looking for ways to improve the performance of your Snowflake queries, then Snowflake Query Acceleration Service (QAS) is a great option to consider.

What is the difference between Snowflake Query Acceleration Service (QAS) and Multi Cluster Warehouse (MCW)?

Snowflake QAS accelerates individual queries by temporarily provisioning additional virtual warehouses to provide extra compute resources for just those specific queries. In contrast, a Multi-Cluster Warehouse (MCW) isolates different workloads across multiple permanent clusters optimized specifically for those workloads to enable concurrency.