Summary

  • Snowflake currently documents QAS enabled by default for newly created Gen2 and multi-cluster standard warehouses, with an automatic maximum scale factor of two. Converting an existing warehouse does not automatically align that state.
  • A specific pending announcement would broaden default activation and set the automatic factor to eight. Its proposed after-state must not be treated as universal present behavior.
  • QAS leases eligible shared compute, bills usage separately and does not guarantee a speedup. A resource multiplier and an estimated query time are not monthly spending limits or completed performance evidence.

Two routes into the same generation

Imagine two standard warehouses bearing the Gen2 label. One was created recently under the documented default. The other began as Gen1 and was converted with QAS disabled. This is an illustrative comparison, not a reported customer deployment. Under Snowflake’s Gen2 guide, creation automatically enables QAS with a maximum scale factor of two; conversion from Gen1 preserves the previous QAS state.

Both warehouses may therefore use the newer generation while differing in permission to obtain acceleration resources. Counting Gen2 warehouses would not establish QAS adoption. Nor would a change request that approves a generation upgrade necessarily record a deliberate decision about that additional resource permission.

That distinction matters to the buyer because “upgrade” often serves as one commercial event: better machinery, an expected performance change and a revised cost expectation. Here the platform preserves a separate setting. The preservation can protect an earlier explicit choice; it can also leave a mixed estate whose behavior is harder to explain. Neither outcome is automatically defective.

The guide says Gen2 is the default for new standard warehouses where that generation is available. Availability has regional and size qualifications, and the generation clause does not apply to Snowpark-optimized warehouses. A portfolio-wide headline should not erase those boundaries before the QAS question has even been reached.

Creation defaults do not reconcile an estate

The 2026_03 behavior-change notice extends the distinction beyond generation. Newly created multi-cluster standard warehouses also receive automatic QAS activation at factor two. Single-cluster Gen1 warehouses remain outside that automatic activation rule. Explicitly enabling QAS uses a different documented default factor: eight.

Altering cluster counts or a scaling policy does not by itself enable QAS. Moving a QAS-enabled Gen2 warehouse back to Gen1 does not by itself turn it off. The resource permission is not a shadow of the current generation or cluster label. It has its own history.

An organization can reasonably choose different settings for different workloads. The commercial weakness arises only when the explanation for that difference disappears. A new warehouse may receive acceleration because a default supplied it, while a converted peer lacks it because an older decision persisted. Comparing their performance without the effective settings would combine hardware, workload and policy differences in one result.

The answer is not to make every warehouse identical. A low-latency recurring workload, an infrequent exploratory workload and a batch job can have different priorities. The buyer needs a defensible exception, not cosmetic uniformity. The useful procurement question is which workloads may lease additional resources, on whose authority, and what benefit would justify their use.

A pending announcement is a different state

As reviewed on 14 September 2026, the specific 2026_06 notice still carries “Pending” in its title. It describes a proposed default that would enable QAS for newly created standard warehouses of all types and make the automatic factor eight. Snowpark-optimized warehouses remain excepted.

That proposed after-state is important planning information. It is not evidence that every account already has it. An enclosing bundle’s status and a particular item’s labelled state are not interchangeable; neither substitutes for the effective warehouse properties in the account being assessed.

The notice also preserves the creation-versus-alteration distinction. Even the broader proposed default would not automatically enable QAS through the listed alterations to an existing warehouse. A larger set of new warehouses receiving the feature would not, on its own, harmonize the older estate.

Buyers should therefore distinguish a documented current baseline, a pending supplier change and an observed account setting. Otherwise an implementation review can approve a proposal as though it were already a measurement, or diagnose a preserved setting as a failed rollout. No account was inspected for this article, and no rollout date is inferred.

The factor authorizes resources, not a result

The QAS guide describes an Enterprise Edition-or-higher feature that offloads eligible portions of query processing to shared compute. Eligibility depends on the query plan and warehouse size; there is no single published scan-size cutoff that makes every query qualify. Additional parallel work can help suitable queries and reduce the impact of outliers, but not every workload has enough useful parallel work.

The maximum scale factor is a resource multiplier based on warehouse size. It is not a promise that a factor of two delivers twice the speed, or that eight means eight times the monthly bill. QAS uses resources it needs and that the service can make available; other concurrent requests and resource availability constrain what can actually be leased.

The documentation says QAS is billed by the second while in use, separately from warehouse usage. Permission to use it is not a charge for an idle entitlement. Equally, faster completion does not alone prove a lower combined cost. The potential trade is extra acceleration credits against shorter work, less outlier interference or a more useful service outcome.

Zero deserves particular care: the documented zero factor removes the upper resource bound. It does not disable QAS. A general convention in which zero means “none” would be economically dangerous if carried into a review of this property. The setting’s actual semantics must survive handover between engineering and budget owners.

Estimates and settlement arrive on different clocks

Snowflake’s estimation-function reference says estimated query times are analytical, not guaranteed, and do not factor in concurrency. The estimate assumes the allocated resources can service the query. It is a way to identify a candidate, not an acceptance certificate for purchased performance.

A fair evaluation needs comparable work and effective settings, not a before-and-after total collected while the demand mix changed. A shorter query can be valuable even without a total credit reduction; a lower credit total can be unhelpful if the required output was not completed. The acceptance object should be useful work delivered within the chosen cost and delay tolerance.

The QAS billing-history view records billed credits over a time window by warehouse and can lag by up to three hours. Its timing is not an instant budget-stop guarantee. Reconciliation with organization-level history also needs aligned time conventions.

There is a further, separate transition cost. The Gen2 guide says that converting a running Gen1 warehouse allows existing queries to finish on the old resources while new queries use Gen2, with both resource sets charged during that overlap. This is a bounded conversion mechanism, not a permanent doubling rule and not the QAS creation default. Mixing the two would make an upgrade’s economic explanation less accurate.

Snowflake offers a legitimate optimization opportunity. The buyer’s task is to keep the generation decision, acceleration permission, observed work and settled credits distinct long enough to judge that opportunity. A label can describe the equipment. It cannot close the bargain.

Sources