From Excel to Warehouse: What the First Week Looks Like

Most analysts who have spent years in Excel approach a direct warehouse connection with a mix of curiosity and wariness. The spreadsheet muscle memory is deep. The uncertainty is: do I have to learn SQL fluently before this is useful? Do my formulas still work? What happens if I accidentally query 500 million rows?

This post covers what the first week actually looks like for an analyst making that transition, including the things that surprise people and the things that feel immediately familiar.

Day One: The Connection and the Schema Browser

The first concrete moment is connecting to your warehouse. In Row Zero, this is an OAuth or password flow (see the Snowflake or BigQuery connector posts for exact steps). Once connected, the schema browser opens on the left. You see a tree: databases, then schemas, then tables and views.

This is the first point of surprise for Excel analysts: there is no file to open. Instead of choosing a file from Finder or Explorer, you are choosing a table from a database. The table is live. It has whatever rows are in it right now.

Spend day one just exploring the schema. Open a few tables and look at the first 100 rows. The Row Zero default preview mode loads a sample without running a full query, so there is no cost concern. You are getting oriented: what columns exist, what data types they use, which tables have the data you care about.

Day Two: Writing Your First Filtered Query

On day two, start with a table you know well from your Excel workflow. If you have been exporting orders data to a CSV every week, find that orders table in the warehouse and open it. Apply a date filter in the column header to scope it to the same time window you usually work in.

This is where the scale difference becomes concrete. If your usual Excel export has 200,000 rows (because that was all Excel could hold comfortably), you can now open 18 months of that same table instead of 30 days. Apply a filter like created_at >= '2025-10-01' in the column header. The warehouse runs a filtered scan and returns the rows in that range.

Your first instinct will be to ask: is this going to be slow? For a table that is already in your warehouse, well-partitioned, with a selective date filter, the query typically returns in a few seconds on any standard virtual warehouse. If it is slower than expected, the usual culprit is a warehouse that was auto-suspended and needs to cold-start.

Days Three and Four: Formulas Against Live Data

Excel-first analysts have strong formula instincts. The good news is that the core formula set carries over. =SUM, =AVERAGE, =COUNT, =SUMIF, =COUNTIF, =VLOOKUP/=XLOOKUP all work in Row Zero. The key difference is that when these formulas reference a column in a warehouse table, they do not compute locally on whatever rows are displayed. They push the computation to the warehouse.

The practical test: put a =SUMIF formula in a cell that totals revenue by a status column. Change the filter on the status column header to narrow the displayed rows. The formula result does not change, because the formula is running against all rows that match the warehouse query, not just the rows you can see in the current view.

This is the moment that usually produces a "wait, how?" reaction. The formula is returning an aggregate over the full dataset, not a local recalculation. That is pushdown working as intended.

One formula that behaves differently from Excel: =VLOOKUP against warehouse data works, but if you are looking up across two large warehouse tables, you are better off writing a SQL join and letting the warehouse handle the matching. =VLOOKUP doing row-by-row lookups against a million-row reference table is not the right tool; a JOIN in the query pane is.

Day Five: Writing SQL in the Query Pane

By day five, most analysts want to try a SQL query. Row Zero has a query pane where you write SQL directly and the result lands in the sheet. This is not required, and some analysts never use it, but for anyone who has done even basic SQL, it is worth trying.

The simplest useful example is grouping data you were previously pivoting in Excel:

SELECT
  DATE_TRUNC('week', created_at) AS week,
  COUNT(*) AS order_count,
  SUM(revenue) AS total_revenue
FROM orders
WHERE created_at >= '2025-01-01'
GROUP BY 1
ORDER BY 1

This runs in Snowflake, returns weekly aggregates, and lands in the sheet as a result table. You can add formulas on top of that result table the same way you would in Excel: percentage change week-over-week, rolling averages, whatever your analysis needs.

For Excel analysts, the learning curve here is not the SQL syntax, which is fairly intuitive. It is the mental model of writing the whole question upfront and getting the result back, rather than building up an answer incrementally by filtering and pivoting a pre-loaded dataset. Both styles work in Row Zero; the SQL path is more efficient for complex aggregations.

What to Expect in Week Two

By the end of the first week, most analysts have settled on a hybrid workflow: SQL in the query pane for multi-table joins and complex aggregations, formulas on top of the results for the analysis layer that changes frequently. The CSV export step, for tables they already have in the warehouse, is gone.

The most common week-two question is about sharing. Row Zero sheets are shareable links. When you send a colleague a link to your sheet, they open it and see the same live warehouse connection with the same query applied. If they want to pivot the analysis, they can apply their own filters or modify the query without affecting your version. There is no emailing files. There is no wondering which version is current.

The adjustment period is real, particularly the mental shift from "I have this data in front of me" to "I am looking at the data in the warehouse." But for analysts who have spent years fighting data size limits, the trade is usually an obvious one.