What Is Snowflake?

Snowflake is a cloud-native data platform built on a unique multi-cluster shared-data architecture that separates compute, storage, and metadata into independently scalable layers. Incorporated in 2012 and listed on the New York Stock Exchange in September 2020, Snowflake helped make the decoupling of compute from storage a mainstream pattern in cloud data warehousing.

This guide explains how Snowflake works, why its architecture matters, what it costs, and where it fits alongside Databricks, BigQuery, and Microsoft Fabric in 2026.

What Is Snowflake?

Snowflake is delivered as a fully managed service - there are no servers to provision, no clusters to size manually, no software to patch. Customers connect to a Snowflake account through a web UI, SQL clients, drivers, or the REST API. Behind the scenes, Snowflake runs on top of one or more public clouds (AWS, Azure, or GCP) but exposes a consistent SQL interface and operational model regardless of the underlying provider.

The product has expanded well beyond its origins as a SQL data warehouse. Snowflake today includes: a data marketplace, native applications, Snowpark (Python, Java, Scala for in-warehouse processing), Streamlit-based UI hosting, Snowflake Cortex (LLMs and ML), and Iceberg table support - alongside the original SQL warehouse.

Architecture: Multi-Cluster Shared Data

Snowflake's signature design is the three-layer architecture. Each layer scales independently. This separation is what enables features like elastic compute, zero-copy cloning, and Time Travel.

Why the architecture matters

In traditional MPP warehouses (Teradata, Netezza, on-prem Vertica) compute and storage are tightly coupled. Adding capacity means adding nodes that bring compute and storage together. Workload isolation requires copying data into a second cluster.

Snowflake's separation lets you:

• Spin up a new compute cluster (virtual warehouse) in seconds without copying data.
• Pay for compute only while warehouses run - warehouses can auto-suspend after an idle period you configure.
• Run multiple workloads (ETL, BI, data science) on the same data with different compute clusters that do not interfere with each other.
• Resize compute up or down with a single SQL command, without redistributing data.

Virtual Warehouses Explained

A virtual warehouse is a compute cluster sized in T-shirt sizes: X-Small, Small, Medium, Large, X-Large, 2X-Large, up to 6X-Large. Each step doubles the credit consumption rate, from 1 credit per hour for X-Small to 512 for 6X-Large; 5X-Large and 6X-Large are generally available in AWS and Azure regions.

Virtual warehouses can be:

• Auto-suspended - stop after N minutes of inactivity. Storage costs continue but compute does not.
• Auto-resumed - resume on the next query. Snowflake describes provisioning as generally very fast, for example 1 or 2 seconds, though it can take longer.
• Multi-cluster - for high-concurrency workloads, spawn additional clusters of the same size as load increases. Used for BI workloads where many users query simultaneously. Multi-cluster warehouses require Enterprise Edition or higher.
• Scaled in seconds - resize up or down with a single SQL ALTER WAREHOUSE. No data redistribution.

Most Snowflake customers run several virtual warehouses tuned to specific workloads - a large one for nightly ETL, a smaller multi-cluster one for BI, a separate one for ad-hoc analyst queries - to prevent workload contention.

Storage Layer

Snowflake stores data in micro-partitions: immutable, automatically created units that each hold between 50 MB and 500 MB of uncompressed data, stored compressed in columnar form. Snowflake's native format is proprietary and managed by Snowflake on the underlying cloud provider's object storage (S3, ADLS Gen2, GCS).

Three storage features stand out:

• Time Travel - query data as of any point within a configurable retention window: 1 day by default, up to 1 day on Standard Edition and up to 90 days for permanent objects on Enterprise Edition and higher. SELECT * FROM customers AT(TIMESTAMP => '2026-04-01 10:00:00') returns the table as it existed at that moment.
• Zero-copy cloning - CLONE creates a new table, schema, or database that shares micro-partitions with the original, so the clone uses no additional storage until either side changes. Snowflake notes that cloning is fast but not instantaneous for large objects.
• Continuous data protection - a dropped object can be restored with UNDROP while it is still inside its Time Travel window. After that, a non-configurable 7-day Fail-safe period follows, from which only Snowflake can recover data, on a best-effort basis.

Since 2024, Snowflake has offered generally available Apache Iceberg tables: tables in the open Iceberg format whose Parquet files can sit in customer-managed Amazon S3, Google Cloud Storage, or Azure storage through an external volume, with either Snowflake or an external catalog managing the table. This brings Snowflake closer to the open-lakehouse pattern also associated with Databricks.

Cloud Services Layer

The cloud services layer is the brain of Snowflake. It coordinates everything that is not pure compute or storage:

• Metadata management - table schemas, statistics, micro-partition info.
• Query optimization and parsing.
• Authentication, authorization, and SSO integration with Microsoft Entra, Okta, etc.
• Transaction management - Snowflake supports ACID transactions.
• Security functions - encryption key management, network policies, dynamic data masking.
• Result caching - Snowflake persists query results for 24 hours, a period that resets each time a result is reused, up to 31 days from the first run; an identical query can return the stored result without re-running while the underlying data is unchanged.

Cloud services usage is billed only when its daily consumption exceeds 10% of that day's warehouse usage.

Key Features

• Snowpark - write Python, Java, or Scala that runs inside Snowflake. Pandas-like DataFrames execute against the warehouse without data movement.
• Streams & Tasks - change-data-capture and lightweight orchestration native to the platform.
• Dynamic Tables - tables that materialize the results of a query and refresh automatically to meet a target lag that sets how fresh the data must be.
• Snowflake Marketplace - curated data products from third-party providers, available without ETL.
• Secure Data Sharing - share live data with other Snowflake accounts (or via Reader Accounts) with no data copied. A direct share works within one region; listings with cross-cloud auto-fulfillment reach consumers elsewhere. Often a deciding feature for B2B data exchange.
• Native Apps - package code, UI (Streamlit), and data into a distributable application that runs in a customer's Snowflake account.
• Snowsight - modern web UI for SQL, Streamlit dashboards, and data exploration.

Snowflake vs Traditional Warehouses

Compared to legacy MPP warehouses (Teradata, Netezza) and earlier cloud warehouses (Redshift original architecture):

• Elasticity - Snowflake scales compute in seconds; traditional warehouses require resizing or migration projects.
• Workload isolation - multiple warehouses on the same data instead of contention or copies.
• Less tuning - no indexes to build, no statistics maintenance, no vacuum. Snowflake's optimizer and micro-partition pruning do most of the work, with clustering keys and search optimization available when needed.
• SaaS operations - no patching, no backup management, no DBA infrastructure work.
• Pricing model - usage-based by the second instead of fixed-capacity license.

The trade-off is reduced control. For standard tables you cannot pick the storage format or manually optimize physical layout (beyond clustering keys), and other engines cannot read the files directly; Iceberg tables are the route for data that has to stay open. For many organizations this is the right trade.

Pricing Model

Snowflake separates two cost streams:

• Storage - billed monthly per TB on the average amount stored after compression, at a rate that depends on cloud, region, and whether it is bought on demand or as pre-paid capacity.
• Compute - billed in credits. An X-Small warehouse consumes 1 credit per hour, and larger warehouses consume credits in proportion to their size: a Medium = 4 credits/hour, a Large = 8, etc. Billing is per second, with a 60-second minimum each time a warehouse starts. The price of a credit depends on the edition (Standard, Enterprise, Business Critical, or Virtual Private Snowflake), the cloud region, and the contract, and rises with the edition (Snowflake cost overview).

The combination of per-second billing and auto-suspend means a well-managed Snowflake account often costs far less than the on-paper credit rate suggests - but ungoverned access to large warehouses is a common route to a surprise cloud bill. Resource monitors, query timeouts, and warehouse size limits are essential.

Snowflake Cortex AI

Snowflake Cortex is Snowflake's AI suite, integrated directly into the SQL surface. Highlights:

• Cortex AI Functions - call hosted LLMs via SQL with functions such as AI_COMPLETE, AI_CLASSIFY, and AI_SUMMARIZE, over models from providers including OpenAI, Anthropic, Meta, Mistral AI, and DeepSeek: SELECT AI_COMPLETE('model_name', prompt) FROM ....
• Cortex Search - managed retrieval over text columns; powers RAG patterns inside Snowflake.
• Cortex Analyst - natural-language to SQL over a semantic view that defines business concepts, metrics, and table relationships, intended for self-service analytics.
• Cortex Agents - orchestrated multi-step LLM workflows that combine tools, retrieval, and Cortex models.

Cortex's distinguishing feature is the data-residency story: Snowflake states that, unless you choose otherwise, all AI models run inside its security and governance perimeter. Cross-region inference is on by default for many accounts: the prompt and response can be processed transiently in another region while stored data stays in the account's region, so teams with residency requirements set CORTEX_ENABLED_CROSS_REGION explicitly. For customers in regulated industries, keeping inference inside Snowflake's perimeter, with the cross-region setting matched to their residency rules, is a meaningful differentiator over patterns that route data to external LLM providers.

Common Use Cases

• Enterprise data warehousing - the original use case. SQL analytics over consolidated business data.
• Multi-cloud analytics - Snowflake replicates data across regions and cloud platforms (AWS, Azure, and GCP); failover and failback require Business Critical Edition or higher.
• Data sharing and B2B data exchange - Secure Data Sharing eliminates the need to FTP files or stand up extract APIs.
• SaaS application back-end - Native Apps and Snowpark let ISVs ship analytical applications inside customers' Snowflake accounts.
• Marketing analytics and customer 360 - high-cardinality joins across CRM, web analytics, and ad platforms.
• Real-time pipelines - Streams + Tasks + Dynamic Tables handle micro-batch CDC patterns; Snowpipe Streaming offers ingest-to-query latency as low as 5 seconds.
• RAG and AI applications - Cortex provides retrieval, models, and orchestration without data movement.

Snowflake's reach has expanded considerably since 2020. It is no longer "just" a warehouse - it is a data platform that competes with Databricks for ML workloads, with Microsoft Fabric for BI integration, and with cloud-native AI vendors for enterprise generative AI. The original architectural decision to separate compute and storage remains the foundation that makes all of it possible. Inside the platform, Snowflake Horizon groups governance such as sensitive-data classification, object tags, masking and row access policies, access history, lineage, and data-quality monitoring, several of them on Enterprise Edition or higher, and it is administered from within a Snowflake account. Dawiso's Snowflake connector brings Snowflake metadata into the same catalog as the rest of the data stack, where ownership, business definitions, and cross-platform lineage are documented; column-level lineage for Snowflake comes from SQL lineage parsing, enabled through Dawiso Customer Success, rather than from a native feed.

Sources

• Snowflake - Snowflake Announces Closing of Initial Public Offering
• U.S. SEC - Snowflake Inc. annual report: Organization and Description of Business
• Snowflake Documentation - Snowflake editions
• Snowflake Documentation - Understanding overall cost
• Snowflake Documentation - Understanding compute cost
• Snowflake Documentation - Overview of warehouses
• Snowflake Documentation - Warehouse considerations
• Snowflake Documentation - Multi-cluster warehouses
• Snowflake Documentation - Micro-partitions & Data Clustering
• Snowflake Documentation - Understanding & using Time Travel
• Snowflake Documentation - Understanding and viewing Fail-safe
• Snowflake Documentation - Data storage considerations
• Snowflake Documentation - Cloning considerations
• Snowflake Documentation - Apache Iceberg tables
• Snowflake Documentation - Using Persisted Query Results
• Snowflake Documentation - Dynamic tables
• Snowflake Documentation - About Secure Data Sharing
• Snowflake Documentation - Introduction to replication and failover across multiple accounts
• Snowflake Documentation - Snowpipe Streaming
• Snowflake Documentation - Snowflake Cortex AI Functions
• Snowflake Documentation - Snowflake AI and ML
• Snowflake Documentation - Cross-region inference
• Snowflake Documentation - Snowflake Horizon Catalog
• Dawiso Help - Snowflake connector