Cloud warehouse
Connect Snowflake to Excel, Sheets and AI
Cloud data warehouse for analytics and streaming exports. Query it with the same read-only SQL you use on Postgres — and join it to a business API in one statement.
One connection, every surface
Where your Snowflake data can go
Connect Snowflake once and the same read-only connection feeds all of these — no second setup, no second copy of the data. 9 of 11 have a step-by-step guide.
Snowflake to Excel
Microsoft Excel · Excel add-in
Pull live Snowflake results straight into a worksheet and refresh them on demand — desktop Excel, Excel Online, Microsoft 365.
Read the guideSnowflake to Google Sheets
Sheets add-on
Run a saved Snowflake query from the sidebar and drop the rows into the sheet. Shared collaborators can refresh it themselves.
Read the guideSnowflake MCP server
Claude, Cursor and MCP clients
Give an AI assistant read-only access to Snowflake with the schema it needs to write correct SQL — no credentials in the chat.
Read the guideSnowflake REST API
HTTP endpoint
Publish a Snowflake query as an authenticated JSON endpoint any application can call, with an OpenAPI 3.1 spec and ready-made Postman, Insomnia and Hoppscotch collections. No database port is opened.
Read the guideSnowflake to Airtable
Automation platform
Sync Snowflake rows into an Airtable base on a schedule, or fetch them inside an Airtable automation script.
Read the guideSnowflake to Baserow
Automation platform
Feed a Baserow table from Snowflake over the REST endpoint — self-hosted or Baserow cloud.
Read the guideSnowflake to SeaTable
Automation platform
Keep a SeaTable base current with Snowflake data without exporting a file or exposing the database.
Read the guideSnowflake to Smartsheet
Automation platform
Push Snowflake results into a Smartsheet grid so plans and reports read from the source system, not last week's export.
Read the guideSnowflake to Anvil
Anvil Works · App platform
Back an Anvil Python app with Snowflake through the REST endpoint instead of embedding database credentials in the app.
Read the guideSnowflake to Power BI
Power Query M
Paste the generated Power Query M into the Power BI Advanced Editor and the report reads live Snowflake results over HTTPS — no ODBC driver, no database port opened.
How Power BI works no Snowflake walkthrough written yetSnowflake alerts and reports
Slack · Discord · Email · Webhook
Put a Snowflake query on a schedule and have the rows delivered to Slack, Discord, email or a signed webhook — or hold the message until a row count, threshold or percentage change crosses the line you set.
How alerts and reports work no Snowflake walkthrough written yetHow it works
5 steps, no inbound firewall change
Install the Network Agent anywhere with outbound HTTPS — Snowflake is reached over the internet, so this can be a small always-on box.
Enter the account identifier, optionally the region, and the database. Warehouse, schema and role are optional; leave them blank and your Snowflake defaults apply.
Choose how to authenticate: password, key-pair RSA, or a programmatic access token. If the account enforces MFA, use one of the latter two.
Pick the databases and schemas worth exposing. The agent reads tables, columns, primary keys and foreign keys so the Query Builder can offer real names and suggest joins.
Write read-only SQL, or let Nova write it. Read the saved query from Excel, Sheets, Power BI, MCP or REST.
Feature deep-dive
What Snowflake gives you
Three ways to authenticate, including the two that survive MFA
Enforced MFA is the usual wall an automated reporting tool hits on Snowflake, because there is nobody at a keyboard to approve a push. Two of the three methods are designed for exactly that.
- Password — the simple case, for accounts without MFA enforced. If MFA is required, the connection test says so in plain words and points you at the alternatives rather than failing with a driver code.
- Key-pair RSA — the usual recommendation for a service connection. Paste the private key or point at a key file on the agent; an encrypted key with a passphrase is accepted.
- Programmatic access token — Snowflake's own token for exactly this kind of caller.
- Role is part of the connection, so the reporting connection can carry a role that can only read, independently of what your own login can do.
- Warehouse is part of the connection too — point reporting at a small warehouse and it stays on the small warehouse.
Discovery that does not give up on the first missing view
Snowflake's INFORMATION_SCHEMA is not uniformly readable: which parts a role can see depends on the grants it holds, and key metadata is often the first thing to be missing.
- Databases, schemas, tables and columns are read from INFORMATION_SCHEMA in batches rather than one round trip per table.
- Where the key-usage view is not readable by your role, the agent falls back to SHOW PRIMARY KEYS and SHOW IMPORTED KEYS per table, in parallel, so relationships still appear in the Query Builder.
- Column precision and scale are preserved on the way into the catalog, so a NUMBER(12,2) is described as one.
Federated joins use the schema, not the database
This is the one detail people get wrong. Your Snowflake database is bound to the connection itself, so in a cross-source query the middle part of a three-part name is the Snowflake schema — usually PUBLIC.
-- warehouse is the connection, PUBLIC is the Snowflake schema
SELECT c.region, SUM(o.total) AS revenue
FROM warehouse.PUBLIC.orders o
JOIN pg_crm.public.customers c ON c.id = o.customer_id
GROUP BY c.region
Shared by every database connector
True of every database connector
- Outbound only — the agent opens one encrypted connection out to Query Streams. No inbound port to forward, no VPN, no IP allowlist, nothing about your database exposed to the internet.
- Credentials stay put — the database username and password live on the machine you installed the agent on. Query Streams never receives them and cannot reach your database on its own.
- Read-only, enforced — one statement at a time, SELECT and friends only. A write is rejected on your own machine before it is ever sent to the server, rather than relying on a permission somebody remembered to set.
- Deploy as many agents as you like — one per site, region or cloud. Every data source they can see arrives in a single dropdown, so nobody has to know which agent hosts what.
What you get once a query is saved
- Share the capability, not the SQL — a colleague or an outside partner can run your query and change its filters without ever seeing the statement behind it.
- Filters from either direction — declare them yourself as @variables, or let the connector spot the literal values already sitting in your WHERE clause and offer those as dropdowns.
- Read it from anywhere — Microsoft Excel, Google Sheets, Power BI, the REST API, AI assistants over MCP, the Query Builder and Nova all read the same saved query.
- Run several at once — five saved queries into five worksheet tabs, streamed concurrently, however large the results.
- Join it to anything else you have connected — another database, a business API, or a folder of files, in one read-only statement.
Cross-source SQL
Join Snowflake to the rest of your data
One statement can span Snowflake and your other connections at once. Each source runs only the part it can, streams the result back, and the join happens centrally — the sources never talk to each other and nothing is copied anywhere.
3 connections · 3 agents
One statement
-- nothing copied, nothing merged, nothing scheduled
SELECT c.region, COUNT(*) AS orders, SUM(i.amount_due) AS invoiced
FROM warehouse.PUBLIC.orders1 f
JOIN pg_crm.public.customers2 c ON c.id = f.customer_id
JOIN billing.stripe.invoices3 i ON i.customer = c.stripe_id
GROUP BY c.region
ORDER BY invoiced DESC;
The three parts are connection, schema and table — and the connection name is whatever you called it. Illustrative columns; your tables will be your tables. Read-only applies to every piece: SELECT, WITH and EXPLAIN only, with a ceiling on how much any one source may hand over for a single query. How federated queries work
Connection details
What Snowflake needs
- Reached over
- HTTPS to your Snowflake account. No inbound anything, and no port to open
- Identified by
- Account identifier, plus region where your account needs one
- Authentication
- Password, key-pair RSA (inline or a key file on the agent, passphrase supported), or a programmatic access token
- MFA
- Password auth cannot satisfy enforced MFA. The connection test says so and names the two methods that can
- Warehouse / role / schema
- All optional and all pinned to the connection. Blank means your Snowflake defaults; schema defaults to PUBLIC
- Driver
- Snowflake.Data 5.1.0, bundled
- Sessions
- Kept alive, so a warehouse that has just resumed does not drop the connection mid-report
- Timeouts
- 30 seconds to connect, 35 seconds per statement
- Read-only
- Enforced on the agent before the statement is sent to Snowflake
Query Streams does not cap what Snowflake bills. There is no credit ceiling and no cost preview here — a query that scans a large table costs what it would cost from any other client. Pinning the connection to a small warehouse and a limited role is the control that actually works.
In a cross-source query the middle part of a three-part reference is the Snowflake schema, because the database is already bound to the connection. A connection called warehouse reading the PUBLIC schema is written warehouse.PUBLIC.orders. Within a single Snowflake connection you can still write Snowflake's own three-part database.schema.table form in a saved query.
Vendor documentation: www.snowflake.com
FAQ
Questions about Snowflake
Which tools can read Snowflake data through Query Streams?
All of them, from one connection: Excel, Google Sheets, MCP, REST API, Airtable, Baserow, SeaTable, Smartsheet, Anvil, Power BI, scheduled alerts and reports. Connect the warehouse once and every surface reads the same read-only connection — there is no per-tool setup and no second copy of the data.
Do I have to open a firewall port to my Snowflake warehouse?
No. The Query Streams Network Agent runs inside your network and opens a single outbound encrypted connection. Nothing listens for inbound traffic, no VPN is required, and the warehouse keeps its existing firewall rules.
Can Query Streams change data in Snowflake?
No. The agent enforces read-only at the point of execution — one statement at a time, SELECT and friends only. Credentials stay on the agent and are never sent to Query Streams.
What does Query Streams need to connect to Snowflake?
A reachable host, a role and its password — the agent carries the driver, so nothing is installed on the warehouse. Reached over: HTTPS to your Snowflake account. No inbound anything, and no port to open. Identified by: Account identifier, plus region where your account needs one. Authentication: Password, key-pair RSA (inline or a key file on the agent, passphrase supported), or a programmatic access token. MFA: Password auth cannot satisfy enforced MFA. The connection test says so and names the two methods that can.
Can I join Snowflake to another database in the same query?
Yes — that is a federated query. One statement can reference Snowflake and your other connections at once, written as connection.schema.table. Each source runs only the part it can and streams the result back; the join happens centrally, so the sources never connect to each other and nothing is copied or scheduled. Read-only applies to every piece — SELECT, WITH and EXPLAIN only — and there is a ceiling on how much any one source may hand over for a single query. Federated queries are a plan feature; the federated queries page carries the current source and size limits.
Put Snowflake where the work happens
Install the agent, point it at your warehouse, and pick a destination.
Read-only Outbound only Credentials stay on the agent

