Product Overview

Overview

Snowflake describes itself as a full data warehouse built for the cloud — a next-generation warehouse built from the ground up for the cloud, rather than an existing database moved onto it.

Its stated vision: every customer can reach all of their data in one place, to make actionable decisions anytime, anywhere, with any number of users.

This page is the product's own framing. The parent page, Snowflake, is what this platform's code actually encodes about it — which is mostly about what it will not enforce. Read together, they are the claim and the measurement.

The three defining properties

The legacy data landscape

Before Snowflake, an end-to-end analytics pipeline was assembled from several separate products. Data sources fall into two groups, and they take different routes.

Read it left to right, and note the two paths.

• Structured sources are pulled by an ETL tool, which connects to the source, extracts, transforms to the business logic and loads into the warehouse.
• Unstructured sources land in a data lake first, are reformatted from unstructured to structured, and only then move into the warehouse — though the lake is also read directly for machine learning.

Datamarts are built on top of the warehouse, one per use case, typically on the same class of product as the warehouse itself.

The criticism of this shape is not that any one product is bad. It is that from source to dashboard you are running several, and every one of them carries its own licence cost and is its own potential point of failure.

The same five layers again, this time by what each one is for. Every layer exists because the layer next to it cannot do its job — which is also why there are five of them.

ETL

The tool that moves data out of the systems that run the business and into the warehouse. Its name is its three steps: extract from the source, transform into the shape the warehouse expects — renaming, recasting types, deduplicating, joining, applying whatever the business logic says a row should look like — and load into the target tables.

It is a layer of its own for two reasons. The transformation runs on the ETL tool's own servers, so it competes with neither the source systems, which are transactional and busy, nor the warehouse, which is sized for reading. And the logic is a codebase in its own right — mappings, workflows, schedules, error handling — owned by a team, versioned, and rarely written down anywhere else.

ETL or ELT is a question about where the transform runs. ETL transforms first, so the warehouse only ever sees finished rows and a separate engine does the work. ELT loads the raw data first and transforms it inside the warehouse in SQL, which needs a warehouse that will accept raw input and can be given more compute on demand. The legacy shape is ETL because a fixed-size warehouse had none to spare.

Enterprise data warehouse

The central store the whole organisation reports from: structured, cleaned, historical data, modelled once and kept for years. One database — which is also what forces two teams' numbers to agree.

It is not the same kind of thing as the databases it is loaded from, even when it is the same product. A source system is transactional — many small writes, current state, one row at a time. A warehouse is analytical — large scans, aggregates over history, whole columns at a time. Same SQL, opposite workload, and that is why the layer is a separate product rather than one more schema on the source server.

It is also sized and licensed up front, because the box is physical. Capacity you did not buy is capacity you do not have on the night the load runs long.

Data lake

Storage that accepts files as they arrive — JSON, CSV, XML, logs, images, audio, Parquet — with no schema required first. The warehouse cannot take them, because a table has to know its columns before a row can land. The lake defers that decision to whoever reads the file.

Two paths lead out of it. One reformats the data into a structured shape and loads it into the warehouse, which is the only way the BI layer will ever see it. The other is read directly for machine learning, which usually wants the raw file rather than the cleaned table.

Nothing checks the contents on the way in, which is both the point of the layer and its risk. A lake with no catalogue over it is where the phrase "data swamp" comes from.

Datamarts

A slice of the warehouse cut for one use case — finance, sales, supply chain — holding that team's tables at the grain they report on and nothing else. It exists so a team's dashboards stay small and fast, and so access can be granted to the slice instead of to the enterprise model.

In this shape a mart is a physical copy, on its own instance of the same class of product as the warehouse, refreshed by a scheduled job. That is the layer's real cost: another licence, another server, another job that can fail — and when it fails, one team reporting yesterday's numbers while the warehouse already holds today's.

BI / analytics

The layer people actually see: reports, dashboards, ad-hoc SQL, and the machine-learning tools reading the lake. It reads from all three stores below it and holds no data of its own, which is why it is the one layer the modern picture leaves alone.

Read the five together and the count is the point. Four of them — ETL, warehouse, lake and marts — move or hold the data, and each is bought, sized and operated on its own. The next section is what happens when one product does all four.

The modern data landscape

The sources do not change and the BI layer does not change. What changes is the middle: one product now occupies four of the boxes.

Snowflake can serve as the enterprise data warehouse, as the data lake, as the datamarts, and as the ELT tool that loads them. The legacy picture needed a separate product for each; here they are one account.

Two things follow. Everything is under one umbrella, so there is one system to buy and operate rather than four. And when something goes wrong there is one place to look — your Snowflake account — instead of a chain of products each of which might be the cause.

Good to know: the datamarts become logical in this picture. In the legacy shape a datamart is a physical copy on its own product, kept fresh by a scheduled job. Here it is defined over the same tables, so there is no copy to refresh and none to drift.

The six features

Snowflake's own summary of what a warehouse built for the cloud gives you. They are peers rather than a sequence — nothing here flows into anything else. Each one is taken in turn below.

1. Complete SQL database

Prior SQL experience carries over directly. The structure is the same one you already know — databases, schemas, tables, views — and SQL statements work as they did in the products you came from.

2. Self-tuning

You do not have to make sure a query is optimised. If a query is not optimal, Snowflake optimises it and runs it on your behalf.

3. All your data

Any type of data the organisation holds can be stored in one account — structured, semi-structured or unstructured, arriving from different sources.

4. All your users

Because the data sits in a single location, different teams use the same account for different work: a data-exploration team querying it, an ML team training on it, and a BI team building reports on top of it.

5. Pay only for what you use

Billing is credit-based. You pay for the queries you run and the data you store, and nothing else — there is no hidden cost, and no requirement to purchase or commit a block of credits up front.

6. Live data sharing

One copy in one location, so as soon as data updates every reader sees the updated value. There is no state where a table has been refreshed and one team sees one number while another sees a different one. It is a single source of truth for everyone with access.

Where the claims and the code disagree

Two of the six read differently once you have seen what this platform records about the same engine. Neither is wrong — both are narrower than they sound.

Keys are the sharpest case. PRIMARY KEY, UNIQUE and FOREIGN KEY are all accepted and stored, and none of them is ever checked — so SQL that ran against an enforcing database runs here and silently stops guaranteeing what it used to. See Snowflake for the full matrix.

The one-line version: the six features are all about reading data. What they do not mention is the write-time enforcement a transactional database spends its effort on, and that is exactly what a migration into Snowflake has to relocate.

Where this page comes from

The devision, the three properties, the two landscape diagrams and the six features are Snowflake's own product framing, taken from an introductory walkthrough of it. They are recorded here because this is the vocabulary anyone arriving at the platform meets first.

The last section is not from that source — it is this platform's own findings, from engine/capability_matrix.py and app/ai/ddl/dialects.py. Product framing and measured behaviour are kept in separate sections on purpose, so it is always clear which one a sentence is making a claim from.

The layer-by-layer walkthrough under the legacy landscape is not from that source either, and it is not a finding. It is ordinary data-architecture background, written so the boxes in the first diagram mean something to a reader meeting them for the first time; it makes no claim about Snowflake.

See also

• Snowflake — what the platform's code encodes: the capability matrix, the DDL profile, the load rules.
• Official Docs — the verified link set, by topic.
• Side by Side — the engine's behaviour next to PostgreSQL's and SQL Server's.