What You Need to Know About Snowflake Query Acceleration

Every time I created a new warehouse in Snowflake, I'd see it - that "Enable Query Acceleration" checkbox staring back at me.

I'd glance at it, think "I don't need that," and move on. For months, I treated it like one of those features you assume is either too complex, too expensive, or just not relevant to your use case. The kind of thing you tell yourself you'll explore "someday."

Then one day, during a casual conversation with a LinkedIn connection, the Query Acceleration Service came up. They mentioned how it saved them from having to permanently upsize their warehouse.

That's when I decided to actually dig into what this mysterious checkbox does. And honestly? I was mind-blown.

In this blog, I'll walk you through what I learned about Query Acceleration Service. No fluff, just the practical insights I wish I'd known earlier.

What is Query Acceleration Service?

Query Acceleration Service (QAS) is a serverless feature built into Snowflake warehouses. Think of it as on-demand backup compute that kicks in automatically when your queries need extra power.

When you run a query, Snowflake analyzes the query plan in real-time. If it detects the query can benefit from parallel processing, it automatically offloads portions of that work to temporary serverless compute.

Your warehouse keeps running normally. The serverless compute handles the heavy lifting in parallel. Once the query completes, that extra compute disappears.

No provisioning. No manual cluster management. No guessing when you'll need capacity. Snowflake handles it behind the scenes.

How QAS Actually Works

Let's say you're running this query to analyze customer purchase patterns:

SELECT
      c.region,
      p.category,
      COUNT(DISTINCT o.customer_id) AS unique_customers,
      SUM(o.amount) AS total_revenue,
      AVG(o.amount) AS avg_order_value
FROM orders o
JOIN customers c 
	ON o.customer_id = c.customer_id
JOIN products p 
	ON o.product_id = p.product_id
WHERE o.order_date >= '2024-01-01'
GROUP BY c.region, p.category
ORDER BY total_revenue DESC;

You're joining three tables:

• Orders: 2 million rows

• Customers: 20,000 rows

• Products: 70,000 rows

Without QAS, your warehouse does everything sequentially - scan all three tables, join them, aggregate, sort.

With QAS enabled, here's what happens:

1. Snowflake analyzes the query plan and identifies the orders table scan as the heaviest operation. It offloads that scan to serverless compute.

2. While the serverless compute scans those 2 million order rows in parallel, your warehouse simultaneously handles the smaller customer and product table scans.

3. Once the serverless scan completes, the results flow back to your warehouse, which performs the joins, aggregations, and sorting.

The serverless compute then disappears. You paid for maybe 10-15 seconds of acceleration.

Snowflake split the parallelizable work between your warehouse and temporary compute, speeding up the overall query without you managing any of it.

How is QAS different than Multi Cluster Warehouses?

So far, we know that QAS is basically compute working in parallel. Isn't it similar to multi cluster warehouses?

Well, I had similar doubts. So, I decided to dive deep and understand how similar or different are these features from one another

Here are the observations:

Use multi-cluster when: You have 20+ analysts constantly hitting your warehouse during business hours.

Use QAS when: You have a few complex queries that occasionally spike and need temporary power.

Understanding Query Eligibility

Does QAS work on every query? The answer is no.  Not every query can be accelerated.

For QAS to help, a query needs two things:

1. Parallelizable operations – Like large table scans, joins, or aggregations that can be split across multiple compute resources.

2.  Significant data volume – The query needs to scan many partitions (a lot of data). Small queries that already run in milliseconds won't benefit.

Simple queries on tiny tables? QAS won't kick in. They're already fast.

Sequential operations that can't be parallelized? QAS can't help.

But large table scans with aggregations across millions of rows? Perfect candidate.

Now, you need not remember these finer details. Snowflake gives you a function to check eligibility before enabling QAS 

1. Run your query and grab its query ID from the history.

2. Use the built in function to check query eligibility

   SELECT SYSTEM$ESTIMATE_QUERY_ACCELERATION('01b2c3d4-e5f6-7890');

If the query is ineligible, you'll get this:

{
    "estimatedQueryTimes": {},
    "originalQueryTime": 45.2,
    "queryUUID": "01b2c3d4-e5f6-7890",
    "status": "ineligible",
    "upperLimitScaleFactor": 0
}

Notice the status: ineligible and empty estimatedQueryTimes. This query won't benefit from QAS.

If the query is eligible, you'll see something like this :

{
    "estimatedQueryTimes": {
      "1": 38.5,
      "2": 28.3,
      "4": 18.7,
      "8": 12.4
    },
    "originalQueryTime": 45.2,
    "queryUUID": "01b2c3d4-e5f6-7890",
    "status": "eligible",
    "upperLimitScaleFactor": 8
}

Breaking it down:

• originalQueryTime: How long the query actually took (45.2 seconds)

• estimatedQueryTimes: Estimated completion times at different scale factors

• status: "eligible" means QAS can help

• upperLimitScaleFactor: Maximum useful scale factor

At scale factor 8, this query could drop from 45 seconds to about 12 seconds. That's a 73% improvement.

Understanding Scale Factors

A scale factor is a multiplier that controls how much serverless compute QAS can use. It's expressed as a multiple of your warehouse size.

Example:

If you're running a Large warehouse (8 credits/hour) & you set a scale factor of 4, QAS can use upto 4 × 8 = 32 credits/hour of serverless compute.

The scale factor is a ceiling, not a fixed amount.

If a query can be accelerated with less compute, QAS uses less. You're never charged for more than what's actually used.

Let's use the earlier example - a query that originally took 45.2 seconds:

Notice the pattern?

Going from scale factor 1 to 2 saves you 10 seconds.

But going from 4 to 8 only saves about 6 seconds while doubling the potential cost.

Remember that upperLimitScaleFactor: 8 from the JSON response?

{
    "estimatedQueryTimes": {
      "1": 38.5,
      "2": 28.3,
      "4": 18.7,
      "8": 12.4
    },
    "originalQueryTime": 45.2,
    "queryUUID": "01b2c3d4-e5f6-7890",
    "status": "eligible",
    "upperLimitScaleFactor": 8
}

The upperLimitScaleFactor tells you the point where additional scale factor stops helping. In this example, setting the scale factor to 10 or 12 wouldn't make the query any faster than 8.

The query's complexity maxes out the benefit at scale factor 8.

Enabling and Configuring QAS

If you're creating a new warehouse, just add two properties:

CREATE WAREHOUSE COMPUTE_WH
WITH WAREHOUSE_SIZE = 'LARGE'
ENABLE_QUERY_ACCELERATION = TRUE
QUERY_ACCELERATION_MAX_SCALE_FACTOR = 4;

That's it. QAS is now enabled with a maximum scale factor of 4.

Already have a warehouse? Use this:

ALTER WAREHOUSE COMPUTE_WH
SET ENABLE_QUERY_ACCELERATION = TRUE
QUERY_ACCELERATION_MAX_SCALE_FACTOR = 3;

The moment you run this, QAS starts working automatically. Snowflake will analyze each query and accelerate eligible ones without any additional action from you.

Changed your mind about the scale factor? Adjust it anytime:

ALTER WAREHOUSE COMPUTE_WH
SET QUERY_ACCELERATION_MAX_SCALE_FACTOR = 5;

No need to disable QAS first. Just change the value.

If you ever need to turn it off completely:

ALTER WAREHOUSE ANALYTICS_WH
SET ENABLE_QUERY_ACCELERATION = FALSE;

Two properties. Two lines of SQL. That's all it takes.

What does QAS actually cost?

QAS is billed per-second, only when actively accelerating queries.

QAS Cost = (Warehouse credits/hour) × (Scale Factor) × (Seconds Used) ÷ 3600

Let's say you're running a Large warehouse (8 credits/hour) with a scale factor of 4. A query gets accelerated for 30 seconds.

• QAS cost: 8 credits/hour × 4 × 30 seconds ÷ 3600 = 0.27 credits

• Warehouse cost (already running, past 60-sec minimum): 8 credits/hour × 30 seconds ÷ 3600 = 0.067 credits

• Total cost for those 30 seconds: 0.337 credits

Note: If you're starting a cold warehouse, factor in the 60-second minimum billing for the warehouse itself. QAS still bills per-second regardless.

Without QAS:

• Query runs for 45 seconds on warehouse only

• Cost: 0.10 credits (warehouse already running)

• Other queries stuck waiting in queue

With QAS:

• Query runs for 15 seconds (warehouse + QAS working together)

• Cost: 0.337 credits

• Warehouse freed up 30 seconds sooner for other queries

Yes, the individual query costs more. But you're paying for speed and better concurrency.

QAS makes financial sense when:

• You have occasional performance spikes – A few heavy queries per day, not constant load

• The alternative is upsizing permanently – Paying for a larger warehouse 24/7 would cost far more

• Queue buildup is hurting productivity – Analysts waiting for queries costs time and money

QAS might not make sense when:

• Your queries are consistently heavy all day (consider permanent upsizing instead)

• You're already running the smallest warehouse and cost is extremely tight

• Your queries are already fast and don't qualify for acceleration

That "Enable Query Acceleration" checkbox I used to ignore? It turned out to be one of the simplest ways to handle performance spikes without over-provisioning.

If you're dealing with occasional heavy queries that slow down your warehouse, check which ones qualify using the SYSTEM$ESTIMATE_QUERY_ACCELERATION function. Start with a conservative scale factor like 3 or 4, monitor the results, and adjust from there.

Sometimes the features you overlook are the ones that make the biggest difference.

Want to master Snowflake and prepare for the SnowPro Core Certification?

Check out the Snowpro Core Certification Path on Enqurious Academy and start your certification journey.