Skip to content

Library · Data Practice OS

Snowflake at a glance

Reference guide · Published · Source reviewed

In one line: Snowflake is the managed, SQL-first platform. You give up some low-level control and get a warehouse that mostly runs itself, strong governance, and the easiest data sharing on the market.

How it is built

Snowflake has three layers. Each one scales and is billed separately.

Layer What it does What you manage
Storage Compressed columnar micro-partitions in Snowflake-managed object storage, or Iceberg tables in your own S3 bucket Retention, clustering keys (rarely), Iceberg external volumes
Compute Virtual warehouses: independent clusters, sized XS to 6XL, that suspend when idle Size, auto-suspend, multi-cluster limits, one warehouse per workload
Cloud services Metadata, optimiser, security, transactions, the Horizon governance layer, Cortex AI Almost nothing. This is the part you are paying Snowflake to run

Because storage and compute are separate, Workload isolation costs nothing to set up. Ingestion, dbt builds, Power BI and AI each get their own warehouse, so a heavy month-end build cannot slow the dashboards. Each warehouse is also its own cost line for FinOps.

Snowflake's own tables are proprietary on disk. Its Apache Iceberg tables, managed by Snowflake or by an external catalog, are open and readable by other engines. For the organisation this matters: see Apache Iceberg as the interchange format.

Strengths

Weak spots

  • Heavy, custom engineering. Large streaming workloads, complex Python, and ML training at scale are possible (Snowpark, Snowpark Container Services), but they are not where Snowflake is most mature or cheapest.
  • Unstructured data at volume. Document AI and AI SQL over files work well for moderate volumes. Multi-terabyte image or video pipelines usually fit Databricks better.
  • Cost surprises. Credits are easy to spend. An oversized warehouse with a long auto-suspend, or an AI function run over a whole table, can burn a month's budget in days. See Cost control on Snowflake.
  • Lock-in if you are careless. Native tables and Snowflake-specific SQL (procedures, Scripting) do not move easily. Put transformation logic in dbt and keep shared data in Iceberg.

When to choose Snowflake

Choose Snowflake as the primary, or only, platform when most of these are true:

  1. Most of the workload is SQL: reporting, dashboards, analytics and regulated reporting.
  2. The team is strong in SQL and light in Spark or Python engineering.
  3. Data sharing with other agencies or external parties is a near-term need.
  4. The first AI use cases are "ask the data" and "ask the documents" for business users.
  5. You want the lowest possible platform-operations headcount.

Not when the critical path is streaming telemetry (for example, traffic sensor feeds at second-level grain), large-scale model training, or custom agent systems with many bespoke tools. Those point to Databricks, or to both platforms. See Choosing a platform - Snowflake, Databricks, or both and ADR-001: One platform by default, two only by workload.

Worked example

The registrations and licensing reporting estate is a typical Snowflake fit. It is mostly SQL, it has hundreds of Power BI users, it holds SENSITIVE personal information that needs masking, and other agencies want feeds that sharing could replace. A first slice could look like this:

-- One warehouse per workload, small by default, quick to suspend
CREATE WAREHOUSE wh_ingest     WAREHOUSE_SIZE = 'SMALL'  AUTO_SUSPEND = 60;
CREATE WAREHOUSE wh_transform  WAREHOUSE_SIZE = 'MEDIUM' AUTO_SUSPEND = 60;
CREATE WAREHOUSE wh_bi         WAREHOUSE_SIZE = 'SMALL'  AUTO_SUSPEND = 300
  MIN_CLUSTER_COUNT = 1 MAX_CLUSTER_COUNT = 4 SCALING_POLICY = 'STANDARD';
CREATE WAREHOUSE wh_ai         WAREHOUSE_SIZE = 'XSMALL' AUTO_SUSPEND = 60;

Raw data lands through Openflow or CDC. dbt builds the silver and gold layers, Horizon policies mask licence numbers and addresses, and Cortex Analyst answers "how many heavy-vehicle registrations lapsed last quarter by region" from a semantic view.

Region and certification

Snowflake runs in three Australian regions: AWS Asia Pacific (Sydney), Google Cloud Australia Southeast 2 (Melbourne) and Azure Australia East (New South Wales). All three have completed IRAP assessment at PROTECTED (regions, IRAP). The IRAP page does not name an edition: confirm with Snowflake which edition the assessed controls assume (Business Critical is the usual choice for SENSITIVE data). Sydney runs only a small set of Cortex models natively (llama3.1-8b for completion, plus embedding models such as snowflake-arctic-embed-l-v2.0 and voyage-multilingual-2). Claude models are reached only through AWS_AU cross-region routing, which keeps inference in Australian AWS regions. Azure Australia East runs only embedding models natively and has no Australian cross-region group (model availability, checked 6 Nov 2026; see AI on Snowflake - Cortex). See Governance, security and trust.