Snowflake

Evidence snapshot

Editor's take

Choose Snowflake when workload isolation, managed operations, a choice of major clouds and governed data sharing matter together. Its case is strongest when several teams need their own compute over shared data, or when distributing datasets is part of the product you deliver. Consider BigQuery when its serverless operating model and query or capacity economics fit your workload better. Compare the jobs you run, their concurrency and the data you share. Architecture · Sharing · BigQuery

Where it stands out

Compute isolation gives teams independent capacity. A warehouse is a pool of compute, not a separate copy of your database. An ingestion job and a dashboard team can use different warehouses against the same stored data. Because those warehouses do not share compute resources, resizing one does not resize the other. This lets teams separate competing workloads and assign capacity to each. Architecture · Warehouses

The purchase can extend beyond SQL warehousing. Snowpark adds Python, Java and Scala development; Iceberg tables provide a route to lake storage; streaming ingestion, Cortex AI, and application features extend the platform's scope. The buying question becomes which parts of your data workflow belong together. Consolidating them may reduce the number of systems a team coordinates. Start with workloads where sharing data and operations would save your team work. Platform scope

Sharing changes how you deliver datasets. Secure Data Sharing exposes selected objects read-only to other Snowflake accounts. Same-region direct sharing avoids copying the underlying data, and consumers use their own compute to query it. For organizations distributing governed datasets to partners or other teams, this changes the delivery and access-management workflow. Cross-region distribution needs its own setup and cost estimate. Sharing

Trade-offs

• Managed infrastructure still needs workload ownership. Someone must choose warehouse capacity and control how long it runs. Separating workloads makes their compute independent, but also creates several consumption streams to budget. Test representative queries and overlapping jobs before extrapolating from one successful trial query. Warehouses
• Platform scope can widen the bill. Serverless services and applicable transfers add charges beyond warehouse compute and storage. Before consolidating another workload, identify its billing unit and the team responsible for it. Credit rates also depend on deployment and commercial terms. Billing
• Recovery depends on retention. Time Travel can restore dropped objects within their configured retention period. Set that period to match your recovery requirements. Retention

Pricing

To estimate a month, record each warehouse's size and running time, then apply the relevant credit rate and add the other billing dimensions. Region, edition and contract rates remain required inputs. The trial can help measure a workload, but its balance is not a production budget. See the pricing guide. Billing · Trial

Alternatives

• BigQuery: compare on-demand bytes processed with slot-capacity pricing against the same query workload. That comparison needs scanned data or capacity requirements, not a conversion from Snowflake credits. Storage is separate. Cost guidance
• Redshift Serverless: consider it when operating within AWS is a priority. Don't compare unit rates directly: RPUs and Snowflake credits meter different things. Measure capacity and runtime, then add storage. Pricing
• Databricks: consider its lakehouse when Spark data engineering and machine learning need to share a platform with SQL analytics. Evaluate that workflow alongside Snowflake's consolidation case. Platform scope

Evidence

Architecture, warehouses, sharing, BigQuery's operating model and Databricks scope verified October 10, 2026; billing, trial, recovery and alternative rates October 9. A comparable workload total needs regional contract rates and measured usage.