Snowflake pricing is consumption-based, which means buyers are not just selecting an edition but also choosing how much compute and storage they will consume over time. For B2B teams, that makes cost predictability less about a flat subscription and more about understanding credits, warehouses, storage billing, and the cases where Snowflake-managed services add charges.
What it is and who it’s for
Snowflake sells its service through a consumption-based pricing model. The pricing page organizes commercial choices around editions and buying motions rather than a single flat plan.
The edition lineup starts with Standard, which Snowflake describes as an entry-level introductory offering with core functionality. Enterprise is positioned for high-growth, large-scale customers, while Business Critical is aimed at highly regulated industries with sensitive data requirements. Snowflake also offers Virtual Private Snowflake, or VPS, as a separate Snowflake environment isolated from all other Snowflake accounts.
This model fits teams that expect infrastructure usage to vary by workload. Data platform owners, analytics leads, and procurement teams evaluating Snowflake pricing need to assess both the edition that matches governance or isolation requirements and the operational patterns that will drive consumption.
How it works
Compute in Snowflake is represented as credits. The core buyer concept is that different kinds of activity draw from that credit-based meter in different ways.
Virtual warehouses are the main compute layer for queries and all DML operations, including loading data into tables. A warehouse is defined by its type, size, and other properties that control and automate activity, and it can be started, stopped, or resized at any time, including while it is running.
Snowflake supports Standard and Snowpark-optimized warehouse types. Warehouse size determines the compute resources available per cluster, and larger sizes approximately double both compute power and credits billed per full hour at each step.
Snowflake bills warehouse usage per second, with a 60-second minimum each time a warehouse starts or resumes. Warehouses are billed only while running, and suspended warehouses do not consume credits. Auto-suspend and auto-resume are enabled by default, and both settings apply to the entire warehouse rather than to individual clusters.
Snowflake also uses Snowflake-managed compute in some cases. Serverless features run on serverless compute instead of virtual warehouses, while compute pools provide compute resources for Snowpark Container Services. Cloud Services compute is separately managed by Snowflake and supports functions such as login, query display, and request processing.
Multi-cluster warehouses add another scaling path. They increase capacity without changing warehouse size, and Snowflake lists multi-cluster warehouses as an Enterprise Edition feature.
Pricing and cost considerations
Snowflake pricing has two main commercial layers: the edition rate and the usage pattern that determines how many credits and how much storage a team consumes. Snowflake says customers can buy the service either on-demand or through pre-paid capacity.
For the pricing page figures Snowflake publishes for AWS, US East (Northern Virginia), the listed per-credit rates are tied to edition:
| Edition | Listed rate |
|---|---|
| Standard | $2.00 per credit |
| Enterprise | $3.00 per credit |
| Business Critical | $4.00 per credit |
Storage is billed separately from compute. Snowflake says storage is billed monthly based on the average amount of storage used per month after compression, and the listed on-demand storage figure on that pricing page is $23.00 per TB per month for AWS, US East (Northern Virginia).
The biggest practical cost lever for most teams is warehouse runtime. Because billing is per second but starts with a 60-second minimum each time a warehouse starts or resumes, frequent short bursts can still create meaningful billed time if teams repeatedly wake warehouses up for small jobs.
Resizing also has billing implications. When a warehouse is resized to a larger size while running, Snowflake applies a 1-minute minimum charge for the additional compute resources only.
Cloud Services can affect the bill, but not in every case. Snowflake says cloud services usage is charged only if daily cloud services consumption exceeds 10% of daily virtual warehouse usage, and that adjustment is calculated daily in UTC before being summed for the monthly statement.
Serverless usage needs separate visibility in budgeting because charges for serverless features appear as an individual line item on the bill. That distinction matters for teams that assume all Snowflake compute will map back to a warehouse they directly manage.
How to choose
Edition choice starts with workload profile and governance needs. Snowflake’s consumption model is one of the approaches compared in our SaaS pricing models guide. Standard fits buyers looking for core functionality, while Enterprise is the edition Snowflake positions for large-scale growth. Business Critical is the path Snowflake positions for sensitive data requirements in regulated industries.
The next decision is operational rather than contractual: whether the team expects tight control over runtime through user-managed warehouses, or expects meaningful usage of Snowflake-managed services. Virtual warehouses are user-managed, which means customers can directly control their credit consumption through start, suspend, resize, and cluster decisions. This credit-metered model resembles the usage-based structure covered in our Cloudflare Workers pricing guide.
Teams expecting concurrency pressure should also examine whether they need multi-cluster warehouses, since Snowflake identifies that capability as an Enterprise Edition feature. Buyers that need environment isolation should evaluate Virtual Private Snowflake rather than assuming the standard shared environment model will satisfy that requirement.
Limitations and gotchas
Snowflake pricing is controllable, but not fully predictable from the public pricing page alone. The company points buyers to the Snowflake Service Consumption Table for specific pricing details, which means the headline pricing page is only part of the budgeting picture.
The public pricing materials in this source set do not provide exact credit rates for specific warehouse sizes, serverless features, or compute pools. That matters because warehouse size changes compute capacity by step, and larger sizes approximately double credits billed per full hour at each step.
Another common pitfall is assuming all compute is warehouse-based. Serverless features use Snowflake-managed compute instead of virtual warehouses, so spend can appear outside the warehouse patterns an engineering team is actively tuning.
Buyers should also watch for minimum-charge effects around short-lived jobs. A warehouse that starts for a brief task still triggers the startup minimum, and repeated resume events can make intermittent workloads costlier than they appear from raw query duration alone.
FAQ
How is serverless compute metered if a team is not using a virtual warehouse? Snowflake bills serverless compute on compute-hours measured per second and rounded up to the nearest whole second — a different meter from the warehouse startup minimum.
Where are the exact per-feature credit rates published? Not on the marketing pricing page. Snowflake points buyers to its Service Consumption Table for the specific rates behind warehouse sizes, serverless features, and compute pools.
Do Snowflake Marketplace listings follow the buyer’s normal rates on VPS? Not always. Snowflake says Marketplace auto-fulfillment to VPS regions uses VPS rates for compute cost calculation, so isolated-environment buyers should model marketplace usage at those rates.
