Why did Snowflake growth slow in 2024-25?

The two explanations competing for the answer

Almost every analysis of the slowdown lands in one of two camps, and the camps prescribe opposite responses — which is why it matters which one you believe.

Explanation A: it is maturity math. Snowflake crossed several billion dollars of annual product revenue. At that scale, holding a 38% growth rate means adding well over a billion dollars of incremental revenue in a single year — the same percentage that once required a few hundred million. Under this reading, the deceleration from the high-30s into the high-20s is arithmetic, not injury. Every large infrastructure company has traced the same curve: hypergrowth in the sub-$1B era, a steady 5-10 point annual decay through the $2-5B range, and a settling into the teens or twenties. The camp points out that net-new customer counts kept rising and large-account counts (customers spending above $1M trailing twelve months) kept climbing through the period. Nothing broke; the denominator got big.

Explanation B: it is competitive and architectural erosion. Under this reading, the deceleration is structurally different from ordinary maturity because the *shape* of the moat changed. Snowflake's original defensibility rested on three legs: a proprietary micro-partitioned storage format that made data physically expensive to leave, a genuinely superior separation of storage and compute at a time when competitors had not built it, and a consumption model that let spend expand silently as usage grew. By 2024-25, all three legs weakened simultaneously. Apache Iceberg standardized the storage layer across vendors, so data no longer had to live inside Snowflake's format. AWS, Microsoft, and Google shipped credible separated-compute warehouses with aggressive pricing tied to broader cloud commitments. And FinOps practice matured to the point where consumption spend became one of the first line items a CFO could compress without a contract renegotiation.

The two explanations produce different numbers when you model them forward. If A is right, growth decays smoothly and predictably toward a floor set by market growth, and margins hold because pricing power is intact. If B is right, growth decays *and* gross margin and net revenue retention decay with it, because winning workloads increasingly requires discounting against a hyperscaler that can bundle. The evidence in 2024-25 leaned toward "both, weighted toward A, with B explaining the extra slope" — net revenue retention compressed materially from its hypergrowth peak, which is the signature of B, while customer counts kept growing, which is the signature of A. A RevOps team reading this should not treat it as a binary. The practical question is not which camp is correct but how much of the deceleration is unavoidable arithmetic you should plan around versus recoverable competitive ground you should fight for.

There is a third framing worth naming so it does not get smuggled in as a cause: the CEO transition from Frank Slootman to Sridhar Ramaswamy in early 2024. The transition is real and it coincided with the deceleration, but coincidence is not causation here. Iceberg's ecosystem consolidation, hyperscaler warehouse maturity, and the AI-budget reallocation were all visible before the handoff. A leadership change can amplify a slowdown through messaging churn and go-to-market reorganization, and it plausibly did add friction, but treating it as the root cause misreads the timeline and leads to the wrong remediation.

How to decide which explanation is driving your own read

You do not have to guess. The two explanations leave different fingerprints in the reported metrics, and you can separate them with a handful of checks against public filings. The discipline is the same one a RevOps analyst uses on any decelerating book of business: decompose the growth rate into its components and see which component moved.

Start with the decomposition. Revenue growth in a consumption business is the product of three things — the number of paying accounts, the average consumption per account, and the retention of last year's cohort. Net revenue retention isolates the second and third. If NRR is falling while customer count keeps growing, existing customers are consuming less than they used to relative to their prior-year baseline, which points at optimization, competitive workload loss, or both. If NRR holds and customer count growth flattens, the problem is top-of-funnel and market saturation, which is much closer to pure maturity math.

The second check is gross margin and discounting. Maturity math does not compress margin — a bigger denominator does not make each credit cheaper to serve. Competitive erosion does, because deals get won on price. Watch product gross margin and any commentary about pricing in competitive displacements. Flat-to-improving margin alongside decelerating growth is the maturity signature. Margin drifting down alongside decelerating growth is the erosion signature.

The third check is remaining performance obligations and their duration. RPO measures contracted-but-unrecognized revenue. In a consumption model, RPO growth outpacing revenue growth can mean customers are still committing to large multi-year deals even while burning credits more slowly — a sign that the deceleration is timing and optimization rather than lost preference. RPO growth falling *below* revenue growth is a warning sign that future commitments are shrinking.

The fourth check is the mix of workloads inside the platform. This one is not visible in filings and requires talking to customers or looking at product-adoption disclosures, but it is the highest-signal check available. If new workload categories — machine learning pipelines, unstructured data processing, streaming ingestion — are landing on a different platform while the SQL analytics footprint stays put, then the addressable surface is being carved up even though the existing footprint looks healthy. That is the leading indicator of erosion, and it shows up in growth roughly two to four quarters after it shows up in workload placement decisions.

Run all four checks before you form a view. The failure mode in this kind of analysis is anchoring on the single most dramatic narrative — usually the competitive one, because it makes better copy — and then constructing a story that explains a number the arithmetic already explained. If you are a RevOps leader building a forecast that depends on a vendor's trajectory, or a practitioner deciding where to place the next three years of workloads, the decomposition is what protects you from that.

Concrete numbers behind each driver

Here is what can be said with confidence about magnitude, and where the honest answer is "directionally yes, precisely unknown."

The deceleration itself. Snowflake's product revenue growth rate stepped down across fiscal 2024 and fiscal 2025 into the high-20s to low-30s range, with forward guidance below the trailing rate. The absolute dollars added each year kept rising even as the percentage fell — that combination is the clean signature of a large-denominator effect and it is the single most important number in the whole analysis. A company adding more revenue than ever before while reporting a lower growth rate is not shrinking; it is compounding off a bigger base.

Net revenue retention. This is the metric that moved most and matters most. Snowflake's NRR ran well above 150% during its hypergrowth years — a level almost no infrastructure company sustains — and compressed substantially through fiscal 2024 and 2025 into a range still healthy by industry standards but far below its peak. Interpret the level carefully: NRR above 120% still means the average existing customer spent meaningfully more this year than last. The story is not contraction, it is a slower rate of expansion. But the *slope* of the compression is what deceleration is made of, because in a consumption business, expansion of the installed base is the dominant growth engine, not new logos.

Storage versus compute economics. Snowflake's revenue has always been overwhelmingly compute, with storage a relatively small single-digit-to-low-teens share of the total. This matters for sizing the Iceberg threat correctly. Iceberg lets customers keep table data in their own object storage — S3, ADLS, GCS — rather than in Snowflake's internal format. The direct revenue at risk from that shift is the storage line, which is small. The *indirect* risk is much larger and much harder to quantify: once the data is in an open format that any engine can read, the cost of running a competitive bake-off drops from a migration project to a configuration change. That is the real mechanism, and it operates on pricing power and retention rather than on the storage line item.

Hyperscaler price pressure. AWS, Microsoft, and Google all have credible warehouse or lakehouse offerings, and all three can bundle data-platform spend into an enterprise cloud commitment the customer has already signed. That bundling is worth more than any headline per-credit discount, because it converts a new purchase decision into a drawdown against existing committed spend — a procurement path with far less friction. Be skeptical of precise "X% cheaper per query" claims in either direction: warehouse price-performance is enormously workload-dependent, and every published benchmark comparison in this category has been contested by the vendor it disfavored. What is defensible is the structural point: Snowflake now competes against vendors who can make the purchase decision easier, not just cheaper.

AI workload allocation. Enterprise AI spending grew sharply across 2023-25, and a meaningful share of it landed on platforms built around notebooks, model training, and Python-first data engineering rather than around SQL analytics. Databricks in particular grew substantially faster than Snowflake through the period on a smaller base, positioning explicitly around AI and machine learning workloads. Snowflake responded with Snowpark for Python-native processing and Cortex for LLM functions inside the warehouse, but arrived at the AI workload conversation from the analytics side rather than the ML side. Precise share-of-AI-budget numbers circulating in the market are estimates, not disclosures, and should be treated as such — but the direction is not seriously disputed.

Customer concentration and consumption lumpiness. Snowflake's largest accounts represent a disproportionate share of revenue, which is normal for enterprise infrastructure. The consequence in a consumption model is that a small number of large-customer optimization projects can move the reported growth rate. A single enterprise that tunes its warehouse sizing, adds auto-suspend, converts hourly batch jobs to daily, and prunes redundant dbt models can cut its own consumption 20-40% without reducing its business value from the platform at all. When dozens of such projects run simultaneously under the same macro budget pressure, it looks like demand destruction in the aggregate even though it is efficiency.

The pricing-response correction. One claim worth explicitly retiring: "Flex Slots" is a Google BigQuery pricing construct, not a Snowflake product. Snowflake's actual cost-control surface is different — resource monitors that cap and suspend warehouses at credit thresholds, budgets for spend tracking and alerting, warehouse auto-suspend and auto-resume, multi-cluster scaling policies, edition tiers (Standard, Enterprise, Business Critical) with different per-credit rates, and negotiated capacity commitments that trade volume for a lower effective credit price. If you are modeling how Snowflake responds to price pressure, those are the real levers.

Implementation: how a RevOps or data team should sequence its response

The analysis is only useful if it changes what you do. Two audiences need to act on it differently — teams *running* on Snowflake who want to control spend without breaking anything, and teams *forecasting against* the trajectory. Here is the sequencing for both.

If you run on Snowflake, optimize in this order. The ordering matters because early steps are cheap and reversible while later steps carry migration risk, and most teams capture the majority of available savings in the first three.

*Step one: instrument before you cut.* Query SNOWFLAKE.ACCOUNT_USAGE.WAREHOUSE_METERING_HISTORY and QUERY_HISTORY to build a per-warehouse, per-role, per-query-tag credit attribution. You cannot govern what you cannot attribute. Give it two weeks of history minimum so you catch weekly and monthly batch cycles. Most teams discover at this stage that 60-80% of credits come from a handful of warehouses running a handful of recurring jobs — which means the optimization surface is far smaller and far more tractable than "our Snowflake bill."

*Step two: fix auto-suspend and warehouse sizing.* Default auto-suspend settings that are too generous leave warehouses idling on the clock. Tightening suspend intervals on interactive warehouses is the single highest-ratio change available and carries almost no risk, because auto-resume brings them back on the next query. Separately, oversized warehouses are common: teams size up to fix a slow query, the query gets fixed, and the size never comes back down. Right-sizing is trial-and-error but bounded — test one size down, measure query duration, keep it if the wall-clock cost is acceptable.

*Step three: put governance on the growth path, not the current bill.* Resource monitors with notify-then-suspend thresholds, per-team budgets, and mandatory query tagging on every scheduled job. This does not save money today; it prevents next year's surprise. Tie the tags to the team that owns the workload so the credit report is a conversation with an owner rather than a mystery.

*Step four: attack the batch schedule.* This is where the real money usually is. Hourly refreshes that nobody looks at hourly, full-table rebuilds where incremental models would work, dbt DAGs where twenty models rebuild because one upstream source changed. Converting a handful of high-cost models from full-refresh to incremental, and dropping refresh frequency on tables with daily-or-slower consumption patterns, routinely delivers larger savings than every warehouse-sizing change combined.

*Step five, and only then, evaluate architecture.* External Iceberg tables, moving cold data to your own object storage, or routing specific workload classes to a different engine. These are real options and Iceberg support makes them genuinely available — but they are migration projects with operational cost, and running them before steps one through four means you are migrating an unoptimized workload and will be disappointed by the savings.

If you forecast against the trajectory, the sequencing is different. First, separate the arithmetic from the erosion using the four checks in the decision section, and carry them as distinct lines in your model — a maturity decay curve and a competitive-loss adjustment. Second, watch NRR and gross margin together every quarter; divergence between them is your early warning that the mix has changed. Third, track where new workload categories land in your own accounts, because your customers' placement decisions lead the reported financials by several quarters. Fourth, resist the urge to model a single narrative. The honest forward view in 2024-25 was a company still growing meaningfully, still adding record absolute revenue, facing a genuinely thinner moat than it had in 2021, in a market that itself was still expanding. All three of those things were true simultaneously.

The broader lesson for anyone building a consumption-priced business is the one that generalizes past this vendor. Consumption pricing is a growth accelerant when customers are expanding and a growth drag when they are optimizing, and the switch between those two regimes is controlled by the customer's CFO, not by your product. Companies that build only for the expansion regime discover the drag all at once. The durable response is to make the platform the place where new workload categories land, so that expansion resumes from new surface area rather than from more consumption of the same surface area — which is exactly the contest the AI workload shift represents.

Related questions

Did the CEO change cause the slowdown?

No. The transition from Frank Slootman to Sridhar Ramaswamy in early 2024 coincided with the deceleration, but Iceberg's ecosystem consolidation, hyperscaler warehouse maturity, and AI budget reallocation were all visible beforehand. A leadership change can add messaging friction; it did not create these headwinds.

How much revenue does Apache Iceberg actually put at risk?

Directly, very little — storage is a small share of Snowflake's revenue and compute dominates. The real exposure is indirect: open formats cut the cost of switching engines from a migration project to a configuration change, which pressures pricing power and retention rather than the storage line.

Is decelerating growth the same as losing?

No. Snowflake continued adding record absolute revenue while its percentage growth fell, which is arithmetic on a larger base. Losing would look like shrinking customer counts, negative net revenue retention, or margin collapse. Watch those three, not the headline growth rate alone.

What is the fastest way to cut a Snowflake bill?

Attribute credits by warehouse and query tag first, then tighten auto-suspend and right-size oversized warehouses. Those two changes are low-risk and reversible. Batch-schedule redesign — incremental models, lower refresh frequency — usually delivers more, but takes longer.

Why did Databricks grow faster over the same period?

Smaller revenue base plus a positioning advantage in machine learning and Python-native data engineering, exactly the workload categories where enterprise AI budgets expanded most sharply. Snowflake approached that conversation from SQL analytics and had further to travel.

FAQ

Is Snowflake's growth slowdown permanent?

The law-of-large-numbers component is permanent in the sense that percentage growth never returns to hypergrowth levels off a multibillion-dollar base — that is arithmetic. The competitive component is not necessarily permanent; it depends on whether the platform captures a durable share of new workload categories rather than defending the existing analytics footprint.

Does open table format support help or hurt Snowflake?

Both, and which dominates depends on execution. Supporting Iceberg lowers the barrier to bringing external data into Snowflake compute, which is additive. It also lowers the barrier to taking data out, which is subtractive. The platform wins this trade only if its compute engine and surrounding governance stay differentiated enough to be chosen on merit.

How should I read net revenue retention on a consumption vendor?

As the expansion rate of last year's cohort, not as a health score. NRR above 100% means existing customers spent more than last year. A fall from 150% to 125% is a slower expansion rate, not contraction. Read the direction and the slope, and always alongside gross margin — the two moving together signals price competition, NRR moving alone signals customer optimization.

Are the specific percentage claims about competitor pricing reliable?

Generally no. Warehouse price-performance is heavily workload-dependent, and nearly every published comparative benchmark in this category has been disputed by the vendor it disfavored. The structurally defensible claim is that hyperscalers can bundle data-platform spend into existing cloud commitments, which reduces purchase friction independent of headline price.

What is Snowflake's actual answer to cost pressure?

Resource monitors that cap and suspend warehouses at credit thresholds, budgets for tracking and alerting, warehouse auto-suspend and auto-resume, multi-cluster scaling policies, edition tiers with different per-credit rates, and negotiated capacity commitments that trade committed volume for a lower effective rate. Note that "Flex Slots" is a Google BigQuery construct, not a Snowflake offering — it appears in secondhand analyses by mistake.

Should a RevOps team change vendors because growth is slowing?

Vendor growth rate is a poor input to your own architecture decision. What matters is price-performance on your workloads, the ecosystem your team already knows, and the cost of the migration itself. A decelerating vendor with a mature product and strong margins is often a better operational partner than a hypergrowth one still stabilizing its platform.

Sources

• https://investors.snowflake.com/
• https://www.sec.gov/cgi-bin/browse-edgar?action=getcompany&CIK=SNOW&type=10-K
• https://docs.snowflake.com/en/user-guide/cost-understanding-overall
• https://docs.snowflake.com/en/user-guide/resource-monitors
• https://iceberg.apache.org/
• https://docs.snowflake.com/en/user-guide/tables-iceberg
• https://aws.amazon.com/redshift/pricing/
• https://learn.microsoft.com/en-us/fabric/enterprise/licenses
• https://www.databricks.com/blog
• https://cloud.google.com/bigquery/docs/reservations-intro

Related on PULSE

• Why did Databricks growth accelerate in 2024-25?
• Why did AWS Redshift adoption increase in 2024-25?
• Why did Salesforce growth slow in 2025?
• Why did HubSpot's customer growth slow in 2025?
• How do you forecast a consumption-priced product line?