dbt Models in the Spreadsheet: Querying Your marts Layer Directly
If your data team uses dbt, your mart layer is where the work lives. Models like fct_orders, dim_customers, mart_revenue_daily are the outputs that analysts are supposed to be working with. The problem is the path between "dbt model ran successfully" and "analyst has the data in a usable form" has usually required an export step or a BI tool that someone else set up.
Row Zero connects directly to the warehouse and lets you query your dbt mart models the same way you'd query any other table. There's no export. No pre-built dashboard. You open the warehouse, browse to your mart schema, and start exploring.
What dbt Actually Writes to Your Warehouse
When dbt runs a model, it materializes it into your warehouse as one of four types: table, view, incremental table, or ephemeral (ephemeral models don't write to the warehouse directly). For analyst access purposes, the distinction that matters is whether you're querying a table or a view.
A materialized table is a physical copy of the data at the point when dbt last ran. If your fct_orders model runs on a 6am schedule, the data you see is as of 6am. If it ran this morning and it's now 3pm, any orders that came in during the day aren't in the model yet.
A view executes the underlying query at query time against the source tables. If your orders_enriched view joins raw_orders with dim_customers, every time you query the view you're running a fresh join against the current state of those source tables. This is always up-to-date, but it costs more on every query because the computation runs each time.
Incremental models are materialized tables that only process new or changed rows on each run. They look like regular tables to an analyst, but their freshness depends on how often the incremental job runs and whether it's caught up with recent data.
Row Zero shows you the object type in the schema browser. Table, view, or materialized view, you can see what you're working with before you query it.
Connecting to Your marts Schema
When you set up a connection in Row Zero, you specify the warehouse, database, and default schema. For a dbt-first data team, the typical setup is to point at the schema where your mart models live. In Snowflake this might be ANALYTICS.MARTS. In BigQuery it might be a dataset called marts or reporting. In Redshift it's likely a schema called dbt_marts or similar.
Once you've connected, the schema browser shows you the available models. You can expand a model to see its column names and data types, which Row Zero pulls from the warehouse's information schema.
To open a mart model in a sheet, you write the query in the formula bar the same way you would in any SQL editor:
=QUERY("
SELECT
order_date,
region,
product_category,
SUM(revenue) AS total_revenue,
COUNT(DISTINCT order_id) AS orders
FROM mart_revenue_daily
WHERE order_date >= DATEADD('day', -30, CURRENT_DATE)
GROUP BY 1, 2, 3
ORDER BY 1 DESC, 4 DESC
")The result lands in the spreadsheet as live data. No copy, no paste, no export. If you want to refresh it, you run the query again. Row Zero will re-execute it against the warehouse and update the sheet.
The Layering Benefit: Marts as a Stable Interface
One thing we hear from data engineers is that they spend time fielding analyst requests to join raw tables directly. An analyst needs order revenue by region, and they join raw_orders with raw_customers themselves, getting slightly different results than the canonical mart model because they applied different join logic or a different filter on order status.
Marts exist to solve this. A fct_orders model is supposed to be the canonical definition of what constitutes a valid order, what its revenue attribution looks like, and which dimensions are joined in correctly. When analysts query the mart directly instead of reconstructing the logic themselves, you get consistency without enforcement effort.
Row Zero makes this easier to maintain because analysts don't need to understand the raw table structure to get useful work done. They can filter and aggregate on top of the mart without touching the underlying joins that the data team owns.
Using Spreadsheet Formulas on Top of dbt Models
Once a query result lands in a sheet, it becomes data you can reference with standard spreadsheet formulas. If you've pulled mart_revenue_daily into Sheet1 with a 30-day filter, you can use SUMIF, VLOOKUP, pivot tables, or any formula that references ranges to build derived views on top of it without writing additional SQL.
This hybrid approach suits analysts who are comfortable with spreadsheet formulas but don't want to write SQL for every downstream calculation. The mart provides the well-defined, clean data layer. The spreadsheet layer handles the ad-hoc aggregation, formatting, and presentation work that analysts typically do in Excel anyway.
Where This Gets Complicated: Ephemeral Models and CTE Chains
Ephemeral dbt models don't write to the warehouse, so they're not directly queryable. If your data team uses a lot of ephemeral models for intermediate transformations, analysts won't see those in the schema browser because they don't exist as warehouse objects. Only the models materialized as tables or views are accessible from Row Zero.
If you find yourself wanting to query logic that's inside an ephemeral model, the options are to ask the data team to materialize it as a view, or to replicate the relevant transformation in your spreadsheet query. The second option is fragile: if the dbt model definition changes, your manual SQL won't stay in sync. When in doubt, ask for a view.
A dbt-first data team that wants analysts in Row Zero benefits from a clear convention: mart models that analysts should use are materialized as tables or views in a well-named schema. Staging and intermediate models stay out of analyst-facing schemas. That separation reduces confusion and keeps the schema browser useful rather than noisy.