What is Snowflake, and what do the job ads really ask for?

First, the thing that sends half the people searching for this to the wrong page. The snowflake schema is a way of modelling a data warehouse and it predates the company by decades. Snowflake, capitalised and sitting in the stack of a job ad, is a product: an analytical data warehouse you use from the cloud and talk to in SQL.

That one sentence is enough to read the ad. What the ad does not tell you — and neither does the product page — is what the work behind it looks like, and that is what decides whether it fits you or whether the first technical call is going to be uncomfortable.

What follows is what I see in the data roles I put in front of candidates, and what I would check before writing "Snowflake" on a CV.

What it is, and what it is not

It is a data warehouse sold as a service: you install nothing and no server is yours. It runs on whichever cloud the company picked (AWS, Azure or Google Cloud), and what you see is a database you send SQL to. Underneath it does not resemble Postgres or SQL Server in much of what matters day to day.

What changes for whoever runs it

The difference every ad takes for granted is that compute and storage are separate. The data lives in one place, and the machine that runs your query — a virtual warehouse — is a different thing that starts and stops on its own and whose size you choose. Two teams can read the same tables without competing for CPU, and you can double the power of the nightly job without touching anything else. It is spelled out in Snowflake's own documentation on warehouses.

If you come from running a traditional engine, that has fairly concrete consequences:

• Most of the infrastructure work disappears. No patching, no sizing disks, no building replicas, no restore drills. No indexes either: Snowflake organises storage by itself into micro-partitions.
• Tuning becomes a different game. How the query is written, and how big the warehouse running it is. On very large tables you add clustering, which is how the data is grouped underneath.
• Permissions weigh more than you expect. Roles and grants are the whole security model, and they are the first thing to break once several teams are in there.
• And a new responsibility shows up, which is the section further down.

Coming from a DBA background this first reads as "half my job is gone". It is closer to half the job moving: what used to be keeping the server up is now modelling properly and keeping the bill from running away. The part that does not change — modelling, and being able to walk through a real incident — is in what is a DBA?.

What Snowflake job ads actually ask for

The first thing, and the one most people underestimate: Snowflake almost never travels alone. IT Jobs Watch counted 510 permanent UK vacancies citing Snowflake in the six months to 17 October 2026 — 0.43% of all permanent vacancies — and of those ads, 60.2% also asked for AWS, 54.1% for SQL, 48.0% for Python and 36.3% for data modelling. The technology the ad is named after is less than half the requirement.

In the data searches I run the shape is the same under other names: Snowflake to store and query, plus two pieces around it — something that brings the data in, which for German clients tends to be Azure Data Factory, and Apache Airflow to orchestrate whatever runs overnight. If your CV only covers the middle piece, it shows quickly.

Translated into what you are expected to be able to do:

• Real SQL, not query-the-table SQL. Window functions, CTEs, execution plans and why a query scans far more data than it needs.
• Modelling. Layers (whatever the company calls its raw and its staging), facts and dimensions, keys, history tracking. This is what separates someone who has built a warehouse from someone who has queried one.
• A language for the pipelines, and in practice that is Python.
• Ingestion and orchestration, even when the ad mentions them in passing: how data gets in, and what happens when a step fails at three in the morning.
• Permissions and data governance, as soon as more than one team touches the warehouse.

None of that comes from a product tutorial, which is why a certificate on its own does not move an interview. What moves it is being able to describe a load that broke and what you changed so it would not break again.

The requirement almost no ad writes down: compute is billed by the second

This is what separates someone who has operated Snowflake from someone who has used it. Compute is billed in credits per second of warehouse runtime, with a 60-second minimum every time it starts, and each size step doubles the credits per hour: a Small warehouse burns twice what an X-Small does. That is why auto-suspend is on by default. It is all in the documentation linked above.

The practical consequence is that in Snowflake a badly written query is not "slow": it costs money, and the money is visible to someone who is not you. That is where interview questions come from that simply did not exist on a traditional engine, and it helps to recognise them:

• Why you would separate the warehouse for loads from the warehouse for reporting.
• What you do when a dashboard keeps a warehouse awake all day.
• What size you would give a nightly job, and how you would check it.
• How you find out which pipeline ate the month's budget.

If you have lived through that, put it on your CV in those words. Almost nobody brings it, and it is what turns a profile from "has touched Snowflake" into "has run it".

Who the jump is short for

• From DBA, or from BI with strong SQL: short. You already have the part that takes long to learn, which is modelling and understanding why a query is expensive; what you are missing is the platform's vocabulary. That is weeks, not years.
• From data engineering on Redshift, BigQuery or Synapse: almost nothing. Same way of working under other names, and ads accept it as equivalent experience fairly readily.
• From backend, if your relationship with data is an ORM: longer than it looks. And the hard part is not Snowflake, it is the modelling.
• From analytics, wanting to cross into data engineering: Snowflake is a good door, because your SQL counts from day one. What you have to add is everything around it: Python and orchestration.

And the usual advice, which holds for any technology in a stack: before you commit, open four ads with Snowflake in them and read the rest of the stack. If you already know what sits next to it, the decision is made. If you recognise nothing else on the list, what you are missing is not Snowflake. Ranges and process are published with each search: you can read them in the open searches before you talk to me.