Contextflo Blog

How to enable self-serve analytics on Snowflake with Claude

Connecting Snowflake to Claude or ChatGPT takes 10 minutes. Getting a team to reliably query it takes more. Shared definitions, access controls, gap detection, and what the setup looks like.

June 12, 20266 min readVivek Sah

Connecting Snowflake to Claude takes about 10 minutes. Getting a team of non-technical people to reliably query it takes more. Here's what's involved and where most setups break down.

How to enable self-serve analytics on Snowflake with Claude

The single-user setup

If you're a data engineer or analyst, the path is straightforward. Snowflake has an official MCP server. Configure it with your credentials, point Claude at it, and you can query your warehouse in natural language. Works great when you already know the schema and just want to skip writing SQL.

Snowflake also has Cortex Analyst, which does natural-language-to-SQL natively inside Snowflake. For a deeper comparison of both options, see our Claude with Snowflake guide.

Either way, the single-user case is solved. The problem is scaling it.

What breaks with a team

When you hand a raw Snowflake-to-Claude connection to your marketing lead, product manager, or ops team, five things break:

  • No shared definitions. "Revenue" means different things to different people. Without a single source of truth, Claude interprets it differently each time based on phrasing.
  • No access controls. Everyone with the connection can query everything - salary data, financial tables, PII. There's no per-team scoping.
  • No audit trail. You can't see what questions people are asking, what SQL is being generated, or where answers are wrong.
  • Corrections don't persist. You fix a wrong calculation in one chat. Tomorrow, someone else gets the same wrong answer.
  • Schema is meaningless to non-technical users. Claude sees stg_orders_v3 and guesses. A product manager doesn't know which table has what they need.

What a team setup looks like

The gap between "one person querying" and "a team querying" is a context layer. Something that sits between Snowflake and Claude and provides:

  • Auto-generated schema context - table descriptions, column meanings, relationships. Generated from your Snowflake schema, not manually authored in YAML.
  • Business definitions - what "revenue," "active user," or "churn" means at your company. Defined once, applied to every query.
  • Per-user access controls - marketing sees marketing tables, finance sees finance tables. One Snowflake connection, scoped per person.
  • Saved queries - when a query gets verified, it's saved. Next time anyone asks something similar, the agent reuses the vetted SQL instead of generating from scratch.
  • Gap detection - when someone asks a question and a business term isn't defined, the system flags it. Your data team fills in what's missing from real usage, not a setup checklist.
  • Audit trail - every question, every query, every user logged. Visibility into where the system is working and where it's not.

How to set it up with Contextflo

  1. Create a read-only Snowflake role with access to the schemas you want to expose. Grant SELECT on the tables your team needs.
  2. Connect in Contextflo. Add the Snowflake credentials and select which databases, schemas, and tables to include.
  3. Review auto-generated context. Contextflo reads your schema, source code, and docs, then generates descriptions for every table and column. Refine anything that's off.
  4. Define key metrics. Add business definitions for terms your team uses - revenue, churn, conversion, whatever matters. These become the source of truth for every query.
  5. Set up access controls. Scope tables by user group. Marketing gets marketing tables. Sales gets theirs.
  6. Invite your team. They install the Contextflo MCP server in Claude and start querying. One setup, shared context for everyone.

What this looks like in practice

Tilt, a live-auction marketplace, runs Snowflake + dbt + Amplitude + Dagster with a one-person data team. Before Contextflo, every data question was a 3-5 day ticket. After connecting Snowflake to Claude through Contextflo, their entire team queries the warehouse independently - thousands of queries per month, most of which never touch the data backlog.

One example: a teammate suspected coupon discounts weren't being applied correctly. Instead of filing a ticket, they described the issue to Claude. Claude explored the relevant Snowflake tables, tested the logic, ran controls, and disproved the hypothesis in 5 minutes. Engineering never got involved.

Read the full Tilt story →

Snowflake-specific considerations

  • Warehouse sizing: Contextflo runs read-only queries. An XS or S warehouse is usually enough. Set auto-suspend to 1-2 minutes to keep costs low.
  • Multi-database support: If your data lives across multiple Snowflake databases, Contextflo can connect to all of them under one setup.
  • dbt models: If you use dbt, your transformed tables are what you should expose - not the raw staging tables. Contextflo generates context from whatever schemas you point it at.
  • Cortex Analyst comparison: Cortex requires you to write and maintain YAML semantic models. Contextflo auto-generates context and syncs with schema changes. See our detailed comparison.

Related reading