Getting In: Snowsight and Your First Worksheet

Sign up for a free trial, find your way around Snowsight, and get a real query result back before you've read to the bottom of the page.

The fastest way to understand a data warehouse is to run one query against it, so let’s get you to a result quickly and explain the surroundings on the way there. You don’t need a company account, an admin’s blessing, or a credit card — Snowflake’s free trial is enough to do everything in this series.

The trial

Go to Snowflake’s signup and take the 30-day free trial. It comes with roughly $400 in credits and no commitment — no card required to start, and nothing charges automatically when the clock runs out; the account just stops until you choose to convert it under Admin → Billing. That budget is far more than you’ll spend learning. Warehouses bill by the second while they run and cost nothing while suspended, and the queries in this series run for seconds on the smallest warehouse.

Signup asks you to make a few choices, and it’s worth knowing what each one commits you to.

Edition. The trial defaults to Enterprise, which is the middle tier and — conveniently for learning — the one that switches on most of the features you’ll read about. Snowflake sells four editions, and they’re a strict ladder, each a superset of the one below:

  • Standard — the full SQL warehouse: all the compute, storage, and query features, plus one day of Time Travel and secure data sharing.
  • Enterprise — adds the things larger teams lean on: up to 90 days of Time Travel, multi-cluster warehouses, materialized views, search optimization, and column-level security. This is what the trial gives you.
  • Business Critical — adds compliance and resilience: HIPAA/PCI support, customer-managed encryption keys, private connectivity, and database failover between regions.
  • Virtual Private Snowflake (VPS) — a completely isolated Snowflake deployment for organizations with the strictest requirements.

Nothing in this series needs more than Standard, but starting on Enterprise means a feature won’t be greyed out on you mid-lesson. If your trial happens to land on Standard, everything here still works.

Cloud provider and region. For learning it genuinely doesn’t matter which — pick a region near you and move on. Snowflake runs the same on AWS, Azure, and Google Cloud, and the choice only affects where your data physically sits and, later, latency to other services in that cloud. It’s not something you can change after the fact, though, so if you already know you’ll be pulling data from an S3 bucket in us-east-1, matching that region will save you cross-region transfer costs down the line. For a trial, don’t overthink it.

Once you submit, Snowflake emails you an activation link and spins up the account. Provisioning takes a minute or two.

Account identifiers, and the URL you’ll actually use

Before the interface, a word about how you address your account, because it’s the one piece of Snowflake plumbing that confuses newcomers for far longer than it should — and it’s the thing every driver, connection string, and CLI tool will eventually ask you for.

Every Snowflake account has two names for the same thing:

  • An account identifier in the form orgname-accountname. When you signed up, Snowflake put your account inside an organization (your company or, for a trial, a generated org name) and gave the account a name within it. So the identifier reads like myorg-learning1 — organization, a hyphen, then the account. This is the modern, human-readable identifier, and it’s what you’ll paste into connectors.
  • An account locator — an older, opaque code like xy12345, sometimes with a region and cloud suffix baked in (xy12345.us-east-1.aws). It still works and you’ll see it in older docs, but the orgname-accountname form is preferred now because it’s stable and readable.

You don’t need to memorize any of this to use the web UI, because when you follow the activation link or later sign in at app.snowflake.com, Snowflake’s sign-in flow handles the routing for you: you pick your account from a list (or type the identifier once), and it drops you into the right place. The direct URL for a specific account looks like https://app.snowflake.com/<orgname>/<accountname>/, and once you’ve signed in your browser will remember it.

Where to find your identifier when you need it. In Snowsight, click your account name in the bottom-left corner. The account menu that pops up shows your organization and account name, and there’s a copy account identifier option and a copy account URL option right there. You can also get it in SQL:

SELECT CURRENT_ORGANIZATION_NAME(), CURRENT_ACCOUNT_NAME();

Tuck this away — the moment you go past the browser and try to connect a BI tool, a Python script, or the Snowflake CLI, the very first thing it asks for is that identifier.

Signing in to Snowsight

Once the account is provisioned, you sign in at app.snowflake.com. What loads is Snowsight, the web interface where you’ll spend all your time — writing SQL, browsing objects, managing the account. If you’ve read older tutorials that mention a “Classic Console,” ignore that instinct; the classic UI has been retired, and Snowsight is the whole experience now.

The left navigation is worth a slow, honest tour, because it maps almost exactly onto the mental model from the last post, and the stub tours most tutorials give you skips half of it. Here’s what each area is actually for.

Projects → Worksheets. Where you write and run SQL. This is home base, and where we’re headed in a minute. Grouped alongside it under Projects you’ll find Dashboards and, depending on your account, Notebooks and Streamlit apps.

Projects → Dashboards. A place to pin the result of a query as a chart or table and arrange several of them on one page — a lightweight, built-in BI surface. You won’t need it early, but it’s handy: any query result in a worksheet can be promoted to a dashboard tile, and the tile re-runs the query on a schedule or on demand. It is not a replacement for a real BI tool, but it’s enough to keep an eye on a few numbers without leaving Snowflake.

Data → Databases. A browser for your storage: databases, schemas, and the tables, views, and other objects inside them. Expand SNOWFLAKE_SAMPLE_DATA here and you can drill all the way down to a table, click it, and see its columns, data types, row count, and a Preview of the first rows — all without writing a SELECT. This is the fastest way to answer “what’s actually in here?” and we’ll live in it next post.

Data → Marketplace. A completely different idea that happens to sit in the same menu. The Marketplace is a catalog of live datasets and applications published by other organizations — weather, demographics, financial data, and so on — that you can attach to your own account as read-only databases and query as if they were local, with no copying and no ETL. That’s Snowflake’s data-sharing technology turned into a storefront. You won’t use it in this series, but it’s worth knowing the distinction: Databases is your storage; Marketplace is everyone else’s, offered to you.

Monitoring → Query History. A searchable log of every query the account has run — yours and everyone else’s — with the SQL text, who ran it, which warehouse, how long it took, how many rows and bytes it scanned, and whether it hit the result cache. This is the single most useful diagnostic screen in Snowflake, and we’ll open it in a moment to inspect your very first query. You can filter by user, warehouse, status, and time range, and click any query to see a detailed profile.

Monitoring → Copy History. A narrower log focused on data loading — every COPY INTO that pulled files into a table, with success and error counts per file. You’ll care about this when you start ingesting data; for now, just know it’s where load failures announce themselves.

Admin → Cost Management. The account’s spending dashboard: credits consumed over time, broken down by warehouse and by service, plus your remaining trial balance. On a trial this is the screen to glance at occasionally so you can see how little the learning queries actually cost.

Admin → Resource Monitors. Guardrails on spend. A resource monitor sets a credit budget over a time window and can notify you — or automatically suspend warehouses — when consumption crosses a threshold. On a trial you don’t strictly need one because the account simply stops when the free credits run out, but this is exactly the mechanism a real account uses to keep a runaway query from burning the month’s budget.

Admin → Warehouses. Where virtual warehouses are created, resized, suspended, and configured — the compute side of the account. You can see each warehouse’s size, its auto-suspend and auto-resume settings, and whether it’s currently running. Post three is all about warehouses, so we’ll come back here properly.

Admin → Users & Roles. Account membership and permissions: the users who can log in, and the roles that grant them what they can see and do. This is the machinery behind that USE ROLE line you’re about to run, and post seven is dedicated to it.

Admin → Security. Account-wide security policies — network rules that restrict which IP ranges can connect, session policies, and (on the right editions) more. You won’t touch it in this series, but it’s where an administrator hardens a production account.

Admin → Billing / Contracts. Where a trial converts to a paid account and where payment and terms live. Nothing to do here until you decide to keep the account past 30 days.

That’s the map. Most of it you can ignore for weeks; the two you’ll open constantly are Worksheets and Query History.

A trial account isn’t empty, which is why we can query on minute one. It’s provisioned with a default virtual warehouse or two — typically a COMPUTE_WH — so you have compute available immediately and don’t have to create anything before your first query. Storage is stocked too: every account ships with a shared, read-only SNOWFLAKE_SAMPLE_DATA database full of realistic tables, including the TPCH_SF1 schema we’ll use throughout this series.

Your first Worksheet

Open Worksheets and create one with the + button. You get two flavors when you create one: a plain SQL Worksheet, and a Python Worksheet. Take the SQL worksheet — the Python option runs Snowpark, Snowflake’s DataFrame API, inside a managed Python sandbox, and it’s a genuinely useful thing to know exists, but it’s a topic for much later. Everything in this series is SQL.

A worksheet is a SQL editor with a result grid below it and, in the top-right corner, a set of context pickers — a role picker and a warehouse picker, plus a database/schema selector. Context is the answer to a question Snowflake asks of every statement: as whom, on what compute, against which data? The role you pick decides what you’re allowed to see; the warehouse decides what compute runs your query. You can set all of it with the pickers, or in SQL, which is what we’ll do because it’s explicit and copy-pasteable:

USE ROLE ACCOUNTADMIN;
USE WAREHOUSE COMPUTE_WH;
USE DATABASE SNOWFLAKE_SAMPLE_DATA;
USE SCHEMA TPCH_SF1;

One thing to flag now and explain in full later: a fresh trial logs you in as ACCOUNTADMIN, the most powerful role in the account. That’s expected on a trial — you’re the only user, and someone has to be able to do everything — but it’s a bad habit to carry into real work, because running everyday queries as the top-level admin is exactly the kind of thing that turns a typo into an incident. We’ll set up saner, lower-privilege roles in post seven. For now, ACCOUNTADMIN gets you moving.

Run those four lines, then run a real query against the sample data:

SELECT COUNT(*) FROM snowflake_sample_data.tpch_sf1.orders;

That table has 1.5 million rows, and you’ll have the count back in a moment. Fully qualifying the name — database.schema.table — means it works regardless of the context you set above; once you’ve USEd a database and schema, you can drop the prefix and just write SELECT COUNT(*) FROM orders. We’ll lean on that in the next post.

A note on case, because it trips up newcomers and Snowflake handles it in a specific way. Snowflake folds unquoted identifiers to uppercase. So orders, Orders, and ORDERS all resolve to the same object, stored internally as ORDERS — which is why the sample tables show up in all-caps in the Databases browser even though you can type them in lowercase. The catch: if you ever quote an identifier — "orders" — Snowflake takes it literally, lowercase and all, and that would not match the uppercase ORDERS. The practical rule is simple: don’t quote identifiers unless you have to, write them in whatever case you find readable, and let the folding sort it out.

How the worksheet actually runs

A handful of mechanics that save real confusion later.

Run current vs. run all. The Run button executes the statement your cursor is in. The keyboard shortcut is Cmd-Enter (macOS) or Ctrl-Enter (Windows/Linux) — you’ll use it constantly. To run every statement in the worksheet top to bottom, use the run-all option in the menu next to the Run button (Cmd/Ctrl-Shift-Enter). That distinction matters here — the four USE lines and the SELECT are five separate statements, separated by semicolons, so either place your cursor in each and run them one at a time, or run all. Multi-statement execution runs them in order and shows you the last statement’s result grid, with the earlier ones available in the results dropdown.

Session variables. A worksheet is a session, and sessions can hold variables. You set one with SET and read it back with a $ prefix:

SET min_price = 100000;
SELECT COUNT(*) FROM orders WHERE o_totalprice > $min_price;

The variable lives for the life of the session, so it’s handy for a threshold you reference in several queries. It’s a small thing, but it’s the first hint that a worksheet is a stateful connection, not just a text box — close the tab and reopen it, and the session resets, variables and context alike.

Comments and formatting. The editor understands SQL comments (-- for a line, /* */ for a block), autocompletes table and column names once your context is set, and has a format option that re-indents a messy query. Autocomplete is more than a convenience on Snowflake: because it reads your current database and schema context, it’ll suggest the actual columns of ORDERS as you type, which doubles as a quick way to remember what’s in a table without switching to the Databases browser.

The result grid. Output lands in the panel below the editor: sortable columns, a row count, and a filter box. It’s a working surface, not just a read-out — you can sort and scan a result without re-querying. Two limits are worth internalizing. First, the grid displays at most 10,000 rows — the query may return millions, but the interactive grid caps what it renders, so a SELECT * on a huge table won’t hang your browser; it just shows you the first slice. Second, when you want the whole result, use the Download option above the grid to export it as CSV (or, in newer Snowsight, other formats). The download pulls the full result set, not just the displayed 10,000.

Charts from results. Next to the results grid is a Chart toggle. Flip it and Snowsight turns the current result into a quick bar, line, or scatter chart — pick which column is the axis and which is the value. It’s the same engine that powers dashboard tiles, and it’s genuinely useful for eyeballing a GROUP BY without leaving the worksheet.

A query needs a running warehouse. Compute has to be on for anything to execute. If your warehouse is suspended when you hit Run, Snowflake auto-resumes it — the first query after an idle stretch pays a second or two of startup, then runs normally. A warehouse auto-suspends after a short idle too, so you’re not paying for it to sit there. That’s the reason a query occasionally pauses before it starts: the engine was off, and Snowflake just turned it on for you.

The first-query warm-up: why the cold run feels slow

Run that COUNT(*) right after signing in and it might take a few seconds. Run it a second time and it comes back almost instantly. That gap is worth understanding concretely, because it’s the difference between two very different things happening under the hood — and reading it correctly is your first real Snowflake skill.

Open Monitoring → Query History and find your query at the top of the list. Click it. The detail view breaks the total elapsed time into phases, and on that cold first run you’ll typically see:

  • Queued (provisioning) or a warehouse-start delay — the warehouse was suspended, and Snowflake spent a second or two resuming it before the query could even begin. This is the auto-resume latency, and it’s a one-time cost paid by whichever query wakes the warehouse.
  • Execution — the actual scanning and counting.

Now the caching. That first run was cold in two senses. The warehouse had no data cached locally, so it read the ORDERS micro-partitions from cloud storage into the warehouse’s local SSD cache. And there was no result to reuse. The second run is fast for one of two reasons, and Query History tells you which:

  • If nothing about the query or the underlying data changed, Snowflake serves it straight from the result cache — a stored copy of the previous answer, returned without spinning up the warehouse at all. In the query detail you’ll see it flagged as served from cache, execution time near zero. This cache is account-wide and lasts 24 hours as long as the data hasn’t changed.
  • If you run a similar query — say, the same count with a different filter — the warehouse is now warm: the ORDERS data it needs is already sitting in local cache from the first run, so it skips the trip to cloud storage. Faster, but not free, because it still executes.

So the honest answer to “why did the first one feel slow?” is a stack of small, explainable costs: the warehouse had to wake up, and the data had to be fetched from cloud storage for the first time. None of it is a sign that Snowflake is slow — it’s the system paying setup costs once so that everything after is quick. Getting in the habit of opening Query History to see those phases, rather than guessing, is exactly how you’ll debug a genuinely slow query later.

Checking your credits. While you’re poking around, open Admin → Cost Management and look at the remaining balance and the consumption chart. Run the whole warm-up exercise above and watch how little it moved the needle — a few seconds of an extra-small warehouse is a rounding error against $400. That’s the reassurance to carry forward: learning on Snowflake is cheap, and the tools to see that it’s cheap are one click away.

Final thoughts

Notice how little ceremony that was. No connection strings, no driver install, no DBA to file a ticket with — a browser tab, four lines of context, and a query against a million and a half rows. That frictionlessness is deliberate, and it’s easy to mistake for the whole product. It isn’t. The context you just set by hand — role, warehouse, database, schema — is the skeleton everything else hangs on, and the next post is about the bones.

Next: Databases, Schemas, and the Warehouse That Isn’t Storage

Comments