Snowflake logo

Cloud warehouse

Connect Snowflake to Excel, Google Sheets, AI and REST

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.

Start free 13 destinations

One connection, every surface

Where your Snowflake data can go

Snowflake live tables · read-only
Federated queries + any other connector · one SQL across sources · every plan
Network Agent
  • 1 outbound connection
  • 0 inbound ports
  • read-only · credentials stay put

runs on

Query Streams reads a Snowflake warehouse as live SQL from Microsoft Excel, Google Sheets, Power BI, AI assistants over MCP and a REST endpoint. Three ways in are supported — password, key-pair RSA and a programmatic access token — which matters because Snowflake accounts with MFA enforced cannot use a password from an unattended process at all. Warehouse, role and schema are yours to pin per connection, so a reporting connection can be restricted to a small warehouse and a read-only role and stay that way.

  1. For your team, vendors and partners

  2. 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.

    Snowflake guide

  3. Snowflake 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.

    Snowflake guide

  4. Ask Nova about Snowflake Nova AI · text to SQL

    Ask a question in plain English. Nova already knows your Snowflake tables, writes and runs the SQL, explains the answer and charts it — no query to write, no credentials to hand over.

    How Nova works

  5. Snowflake to Data Viewer result sharing · team, vendors, partners · phone, tablet, desktop

    Share a live Snowflake result with anyone — a colleague, a vendor, a partner — as a bookmarkable grid that re-runs fresh when opened, on a phone, a tablet or a desktop. They see the results, never the SQL or the credentials.

    How the Data Viewer works
  6. For apps and systems

  7. Snowflake 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.

    Snowflake guide

  8. Snowflake 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

  9. Snowflake to Airtable Automation platform

    Sync Snowflake rows into an Airtable base on a schedule, or fetch them inside an Airtable automation script.

    Snowflake guide

  10. Snowflake to Baserow Automation platform

    Feed a Baserow table from Snowflake over the REST endpoint — self-hosted or Baserow cloud.

    Snowflake guide

  11. Snowflake to SeaTable Automation platform

    Keep a SeaTable base current with Snowflake data without exporting a file or exposing the database.

    Snowflake guide

  12. Snowflake 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.

    Snowflake guide

  13. Snowflake 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.

    Snowflake guide
  14. For AI tools

  15. Snowflake 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.

    Snowflake guide
  16. Delivered to people

  17. Snowflake 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

How it works

5 steps, no inbound firewall change

01

Install the Network Agent anywhere with outbound HTTPS — Snowflake is reached over the internet, so this can be a small always-on box.

02

Enter the account identifier, optionally the region, and the database. Warehouse, schema and role are optional; leave them blank and your Snowflake defaults apply.

03

Choose how to authenticate: password, key-pair RSA, or a programmatic access token. If the account enforces MFA, use one of the latter two.

04

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.

05

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

Snowflake Cloud warehouse
PostgreSQL Relational engine
Stripe Payments & billing

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.

Start free All connectors

Read-only Outbound only Credentials stay on the agent