Ask Snowflake Questions in Plain English

Asking Snowflake questions in plain English has two constraints that other engines do not impose: every query costs warehouse credits, and the role model needs four separate grants before anything works. Neither is hard, but both are easy to get wrong in ways that look like product failures. This guide covers the grants, the cost guards worth setting, the dialect specifics that change generated SQL, and the case for choosing a warehouse-native tool instead.

What this assumes about your account

Data engineers and analytics owners running Snowflake who are evaluating whether to let people ask questions in plain English against it, and who will be the one explaining the credit line if it goes wrong. It assumes you can create a role and grant privileges. Step-by-step connection setup is in the Snowflake connection guide.

The role model is four grants, not one

The grant script

CREATE ROLE datarelix_reader;

GRANT USAGE   ON WAREHOUSE your_warehouse TO ROLE datarelix_reader;
GRANT OPERATE ON WAREHOUSE your_warehouse TO ROLE datarelix_reader;
GRANT USAGE   ON DATABASE  your_database  TO ROLE datarelix_reader;
GRANT USAGE   ON SCHEMA    your_database.your_schema TO ROLE datarelix_reader;
GRANT SELECT  ON ALL    TABLES IN SCHEMA your_database.your_schema TO ROLE datarelix_reader;
GRANT SELECT  ON FUTURE TABLES IN SCHEMA your_database.your_schema TO ROLE datarelix_reader;

CREATE USER datarelix_reader
  PASSWORD = 'choose-a-strong-password'
  DEFAULT_ROLE = datarelix_reader
  DEFAULT_WAREHOUSE = your_warehouse;
GRANT ROLE datarelix_reader TO USER datarelix_reader;

The two lines that get skipped

• OPERATE on the warehouse. Snowflake auto-suspends idle warehouses. Without OPERATE, the first query after a quiet period fails with “Warehouse is suspended” — which reads like an outage rather than a missing grant.
• SELECT ON FUTURE TABLES. Without it, every model your transformation layer adds tomorrow is invisible until someone re-runs the grant. This is a common cause of “it stopped seeing our new tables”.

Full privilege semantics are in Snowflake’s access-control overview.

The account identifier has four forms

This is a common source of failed first connections. The modern, preferred form is orgname-account_name — for example myorg-prod1. The legacy form is <locator>[.<region>][.<cloud>]:

Cloud / region	Example	Note
AWS US West (Oregon)	xy12345	No region segment — the legacy exception
AWS, any other region	xy12345.us-east-2.aws	Region + .aws
Azure, any region	xy12345.east-us-2.azure	Region + .azure
GCP, any region	xy12345.us-central1.gcp	Region + .gcp

Find yours under Admin → Accounts in Snowsight, or read it out of your Snowflake web URL. Snowflake’s own account identifier reference is the authority.

Cost control is a first-class concern

On PostgreSQL an inefficient query wastes a little CPU. On Snowflake it spends credits. Ad hoc natural-language querying can generate more queries than a dashboard workload, so the guards matter:

Guard you set in Snowflake	Effect
Dedicated XS warehouse	Sizes the blast radius. An XS is usually sufficient for analytical questions over modelled marts, and isolating it makes the spend attributable.
Short auto-suspend	Idle time is the main source of surprise credits. Pair it with OPERATE so resume is automatic.
STATEMENT_TIMEOUT_IN_SECONDS	Snowflake’s own default is two days. Set it on the warehouse or the role so a runaway scan is cut short rather than billed to completion.
Scope to modelled schemas	Querying governed marts rather than raw tables is both cheaper and more correct.

Datarelix adds two limits of its own that you do not configure: every query is cut off after 30 seconds, and results are capped at 5,000 rows, so an unbounded question cannot return an unbounded result.

Estimating the credit line

The guards bound the worst case; this bounds the expected one. Snowflake bills warehouse time by the second (60-second minimum per resume), so with your own numbers:

credits/month  =  (questions/day × avg seconds per question ÷ 3600) × credits/hour for the size × 30

An XS warehouse is 1 credit/hour. So 40 questions a day averaging 8 seconds of warehouse time is roughly (40 × 8 ÷ 3600) × 1 × 30 ≈ 2.7 credits/month of query time — before idle. Idle is usually the larger number, which is why auto-suspend matters more than query tuning: the same warehouse left at a 10-minute auto-suspend and resumed 40 times a day bills far more than the queries themselves. Substitute your own question volume and your contract’s credit rate; the point of the formula is that ad hoc volume, not query size, is the variable to watch.

Snowflake dialect specifics that show up in generated SQL

A system that generates generic SQL will produce statements Snowflake rejects. The specifics that actually change output:

• Identifiers fold to uppercase unless double-quoted. A schema built with quoted mixed-case names needs quoting everywhere, forever.
• QUALIFY filters on window functions directly — no wrapping subquery. Generated SQL that uses it is idiomatic Snowflake; the subquery form is equivalent, just more verbose.
• Three-part names — DATABASE.SCHEMA.TABLE.
• Timestamp types — TIMESTAMP_NTZ, TIMESTAMP_LTZ, and TIMESTAMP_TZ are genuinely different. Mixed use in one schema is a real source of wrong time-window answers, and no natural-language layer will rescue you from it.
• Semi-structured data — VARIANT, OBJECT, and ARRAY need LATERAL FLATTEN to unnest. Questions over deeply nested JSON are where generated SQL is least reliable.

Foreign keys are declaration-only, and it matters

Snowflake does not enforce foreign-key constraints on standard tables; they are informational metadata. Many warehouses are therefore built without declaring any. Schema discovery against such a warehouse finds no relationships. That is expected.

The consequence is real: without declared keys, join paths must be inferred from naming conventions, and inference is sometimes wrong. On a warehouse with no declared FKs, check the joins in the first several answers before trusting a number, using the routine in how to verify an AI-generated data answer, and consider declaring keys on your analytics tables purely as documentation. This is the same problem described in why semantic context matters.

Snowflake AI analytics: when a warehouse-native tool is the better answer

Warehouse platforms increasingly ship their own assistants, and there are honest reasons to prefer one:

• Everything you analyse lives in Snowflake, permanently. A tool that only speaks Snowflake has fewer moving parts, and its billing and permissions are already yours.
• You need governance features tied to the platform — platform-level audit trails, row-access policies applied consistently, or identity that never leaves the vendor.
• Procurement strongly prefers one vendor.

The case for an independent layer is the mirror image: you have data in more than one place and want the same question answerable across engines; you want the evidence trail to be a property of the tool rather than a platform feature; or you want portability if the warehouse decision changes. This guide is not a competitor comparison — evaluate the specific products against your own criteria, and use the procurement questions in the security checklist as a starting rubric.

Connecting Snowflake to Datarelix

Datarelix connects to Snowflake with username and password — the only auth mode available today; key-pair and OAuth are not available. The password is stored encrypted. Introspection reads <database>.information_schema for tables, columns, primary keys, and declared foreign keys.

Generated statements are parsed into a syntax tree and rejected unless they are reads — how the validator works — with Snowflake-specific administrative commands blocked as well. INFORMATION_SCHEMA is readable only during discovery, and ACCOUNT_USAGE is always blocked. Multi-statement queries are rejected: one SELECT, WITH, or UNION per question.

Where this breaks on Snowflake

Username/password is the only auth mode, so accounts that mandate key-pair or SSO for service users cannot connect today. Accounts locked to AWS or Azure PrivateLink (a *.privatelink.snowflakecomputing.com URL) accept connections only over the private endpoint and are not reachable from a hosted service. Account or user network policies must list the service’s egress IPs or logins are rejected outright.

Scope is one schema per connection, so cross-schema joins in a single question are out. There is no write path of any kind. Deeply nested VARIANT structures are the weakest area for generated SQL.

Sources

Privilege model per Snowflake access control; identifier forms per account identifiers; network restrictions per network policies. Warehouse behavior per warehouse overview. Product statements describe Datarelix as shipped in August 2026; the security page is canonical. The section on warehouse-native tools deliberately makes no claims about any named competitor’s capabilities.

Run the grant script on one modelled schema

Run the grant script above against one modelled schema, then follow the quickstart and ask a question you can verify from an existing dashboard. Compare the generated SQL to the model behind that dashboard. Your first 14 days run at Pro limits, no credit card required.