How to enable self-serve analytics on Snowflake with Claude

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

The single-user setup

If you are 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 the warehouse in natural language. It works well when you already know the schema and simply want to skip writing SQL.

Snowflake also has Cortex Analyst, which does natural-language-to-SQL natively inside Snowflake. We compare both in Snowflake Cortex Analyst vs Contextflo.

Either way, the single-user case is solved. The problem is scaling it past one person who already knows the data.

What breaks with a team

Hand a raw Snowflake-to-Claude connection to your marketing lead, a product manager, or the ops team, and five things break:

• No shared definitions. Revenue means different things to different people. Without one source of truth, Claude interprets it differently depending on how the question was phrased.
• No access controls. Everyone with the connection can query everything, including salary data, financial tables and PII. There is no per-team scoping.
• No audit trail. You cannot see what people are asking, what SQL was generated, or where the answers were wrong.
• Corrections do not persist. You fix a wrong calculation in one chat. Tomorrow, someone else asks the same thing and gets the same wrong answer.
• The schema is meaningless to non-technical users. Claude sees stg_orders_v3 and guesses. A product manager has no idea which table holds what they need.

The last two compound. A team that keeps getting answers it cannot verify stops asking, and you are back to the ticket queue with an extra subscription.

What a team setup looks like

The gap between one person querying and a team querying is a context layer between Snowflake and Claude, providing:

• Auto-generated schema context — table descriptions, column meanings, relationships, generated from your schema rather than hand-authored in YAML
• Business definitions — what revenue, active user or churn means at your company, defined once and applied to every query
• Per-user access controls — marketing sees marketing tables, finance sees finance tables, from one Snowflake connection scoped per person
• Saved queries — once a query is verified it is stored, and the next similar question reuses that vetted SQL instead of generating new SQL
• Gap detection — when someone asks about a term that is not defined, the system flags it, so your data team fills gaps from real usage rather than a setup checklist
• Audit trail — every question, query and user logged, so you can see where it is working and where it is not

How to set it up

1. Create a read-only Snowflake role with access to the schemas you want to expose, and grant SELECT on the tables your team needs.
2. Connect in Contextflo. Add the credentials and select which databases, schemas and tables to include.
3. Review the generated context. Contextflo reads your schema, source code and docs and describes every table and column. Refine anything that is off.
4. Define your key metrics. Add definitions for the terms your team argues about. These become the source of truth for every query.
5. Set up access controls. Scope tables by group before you invite anyone, not after.
6. Invite your team. They install the MCP server in Claude and start asking.

Step 3 is where the value is, and it is the step people skip. A team querying undocumented tables gets confident nonsense, which is worse than no answer because nobody knows to double-check it.

What this looks like in practice

Tilt, a live-auction marketplace, runs Snowflake with dbt, Amplitude and Dagster, and a one-person data team. Before Contextflo, every data question was a three-to-five-day ticket. Now their team queries the warehouse directly, at around 6,000 queries a month, most of which never reach the data backlog.

One example. A teammate suspected coupon discounts were not being applied correctly. Rather than filing a ticket, they described the problem to Claude, which explored the relevant tables, tested the logic, ran controls, and disproved the hypothesis in about five minutes. Engineering was never involved.

That is the part worth noticing: the valuable outcome was not a dashboard, it was a wrong hypothesis being killed the same afternoon instead of a week later.

Read the full Tilt story →

Snowflake-specific notes

• Warehouse sizing. These are read-only queries, so an XS or S warehouse is usually enough. Set auto-suspend to one or two minutes to keep the bill down.
• Multi-database. If your data spans several Snowflake databases, they can all sit under one connection.
• dbt models. Expose your transformed models, not raw staging tables. Staging tables are where the confusing names live, and they are the ones an LLM will misread.
• Versus Cortex Analyst. Cortex asks you to write and maintain YAML semantic models. The tradeoff is authored precision against generated coverage, and it matters most if you already have those models. Detailed comparison.