Natural Language Analytics

Both Databricks and Snowflake now offer products that let business users type a question in plain English and get a SQL-generated answer. The pitch sounds similar: self-service analytics without SQL expertise. In practice, both platforms require substantial upfront work that is regularly underestimated.

What may not be obvious from product documentation is how structurally similar the underlying requirements have become. Both have converged on the same core architecture: a native semantic layer object that defines business metrics, dimensions, and relationships, consumed by a natural language interface. In Databricks, that object is a Metric View. In Snowflake, it is a Semantic View.

Every implementation decision feeds a causal chain that determines the quality of AI answers across the company:

Both platforms require the same fundamental inputs. None are optional. Each directly determines the accuracy and trustworthiness of the answers the system will produce:

• Agreed-upon metric definitions with canonical aggregation formulas. These become the formulas the AI applies to every question.
• Clean metadata: business-quality descriptions, synonyms, and sample values on every field. This is how the AI interprets business language.
• Explicit join paths declared in advance. Neither platform supports runtime joins. The joins you define are the only joins the AI can use.
• Curated example queries that encode how your organization translates business questions into SQL. High-value institutional logic artifacts, not throwaway test cases.
• Ongoing ownership by someone who understands both the data model and the business context. Without this, the system degrades within months.

The Databricks natural language analytics stack has two layers. The Metric View is a YAML-based semantic layer object in Unity Catalog that defines dimensions, measures, and joins. The Genie Space is the NL configuration layer where example SQL, text instructions, and business context teach Genie how to translate questions. Together, these become the answer substrate for every question a business user asks.

Implementation Steps

Step 1: Scope the Data Domain

Select the tables that will feed the Metric View and define the analytical domain for the Genie Space.

Decide which data the system should answer questions about and limit scope so the AI has fewer possible interpretations.

Identify the business domain the Metric View will serve. Limit scope to one analytical domain per Metric View (sales, marketing, finance). If underlying tables are heavily normalized, create denormalized views or gold-layer Materialized Views. Exclude audit columns, internal IDs, and staging artifacts.

Several hours with clean existing tables. One to two weeks if denormalization is needed.

Most organizations do not have clean, pre-joined views ready. Teams frequently scope too broadly at the start, then narrow after accuracy problems surface. In our experience, Genie Spaces perform best with five or fewer tables. Every additional table increases the probability of confidently wrong answers.

Step 2: Build the Metric View

Define dimensions, measures, joins, and metadata in a YAML-based Metric View object in Unity Catalog.

This is where you encode the official calculations and relationships the AI uses when it writes SQL. Every formula here becomes a production answer ingredient.

All relationships must be declared in the YAML. The canonical aggregation formula for each metric must be agreed upon before it is codified, because once codified, it is the answer the AI will give.

Several days for a small domain (5-8 dimensions, 10-15 measures). Two to four weeks for complex domains.

Organizations often discover during this step that different teams define the same metric differently. That conflict must be resolved before anything is codified. If it is not, the system will freeze one version into infrastructure and serve it as organizational truth.

Step 3: Enrich Metadata and Synonyms

Populate dimension and measure comments, synonyms, and example values inside the Metric View definition.

You are teaching the AI what business terms mean and how users will refer to the data.

This metadata is the primary mechanism Genie uses to match questions to fields. Without rich metadata, Genie guesses, and at scale, guessing means wrong answers delivered to users who have no reason to doubt them.

Several hours for small domains. One to two weeks for complex domains with cross-team terminology.

Step 4: Configure the Genie Space

Add example SQL queries, SQL expressions, text instructions, and join definitions to the Genie Space.

Give the NL interface a library of known-good answers and domain-specific rules. These are encoded precedent that teaches the system how your organization translates business questions into SQL.

The example library is effectively the training data for your domain. Shallow examples create shallow system behavior. The examples that matter most encode how your organization handles ambiguity, edge cases, and contested business logic.

One to two days for 5-10 examples. Two to four weeks for a comprehensive library of 20-50.

Politically convenient examples that avoid the real contested questions the business cares about are dangerous: they leave the hardest, highest-value questions unanchored.

Step 5: Plan Materialization (Optional)

Configure pre-computed aggregations in the Metric View YAML with a CRON refresh schedule.

For large datasets, pre-computing common query patterns speeds up response time without changing the user experience.

Several hours for configuration. One to two days for testing and tuning.

Step 6: Benchmark, Monitor, and Iterate

Run test suites, review user feedback, and update the Metric View and Genie Space as usage patterns emerge.

The semantic layer requires ongoing maintenance. Without it, the system degrades and begins delivering wrong answers with the same confidence it delivers correct ones.

The benchmark suite is an institutional logic artifact: it encodes what “correct” means for your organization.

One day for initial setup. Several hours per week ongoing.

Snowflake’s stack follows a parallel architecture. The Semantic View is a native schema-level object that defines logical tables, dimensions, facts, metrics, and relationships. Cortex Analyst reads it and translates questions into SQL inside Snowflake’s governance boundary. Every definition, join, and verified query you encode determines the answers Cortex Analyst produces.

Implementation Steps

Step 1: Design the Data Model

Identify physical tables, define primary and foreign keys, prepare a star-schema-friendly data model.

Decide what data the system should cover and organize it so the AI has a clean schema to work from.

Current documented guidance suggests a practical limit of roughly 50-100 columns total. If your domain exceeds this, split into multiple semantic views.

Several hours with an existing star schema. One to two weeks if denormalization is needed.

Teams with wide tables need to make scope decisions early.

Step 2: Create the Semantic View

Define logical tables, dimensions, facts, metrics, and relationships using SQL DDL or the Snowsight wizard.

Encode the official business logic. Every definition is a production answer ingredient.

Every COMMENT becomes context for Cortex Analyst, and comment quality directly determines AI accuracy.

Several days for a small domain. Two to four weeks for complex domains.

The most time-intensive step. If a metric formula encodes a disputed definition, Cortex Analyst will serve that definition as organizational truth.

Step 3: Write Verified Queries and Custom Instructions

Add natural-language questions paired with exact SQL answers. Add plain-text custom instructions for domain-specific rules.

Verified queries are encoded institutional precedent: they define how your organization translates its most important business questions into SQL.

One to two days for 5-10 verified queries. One to two weeks for a comprehensive library.

Verified queries must use logical names. Politically convenient examples that sidestep the hardest questions leave the system weakest where it matters most.

Step 4: Enrich Metadata

Write business-quality comments, synonyms, and sample values for every column and metric.

The difference between a generic comment and a business-quality comment is the difference between an AI that interprets questions correctly and one that guesses.

Several hours for small domains. One to two weeks for complex domains.

Step 5: Configure RBAC and Privileges

Grant end-user roles USAGE on the semantic view and SELECT on all underlying tables.

Several hours for straightforward environments. One to two days for complex role hierarchies.

Privilege misconfigurations are the most common source of “it works for me but not for them” issues.

Step 6: Benchmark, Optimize, and Iterate

Run test suites, review optimization suggestions, and update the semantic view as patterns emerge.

Without maintenance, the system returns wrong answers indistinguishable from correct ones.

Two to three days for initial testing. Several hours per week ongoing.

Neither platform creates business truth; both turn whatever definitions the organization provides into production answer logic.

These operational differences matter, but they are usually less determinative of answer quality than semantic readiness, benchmark quality, and business-definition clarity.

Each one results in wrong answers delivered to users who have no reliable way to detect them.

Scoping too broadly

Teams include too many tables or try to cover multiple domains in one semantic object. The AI faces too many interpretations and the probability of confidently wrong answers increases.

Treating setup as a one-time project

Teams that build the semantic layer and walk away see accuracy degrade within months. Without active maintenance, the NL interface delivers wrong answers indistinguishable from correct ones.

Codifying unresolved metric politics

Semantic layers do not resolve business disagreement. They freeze one answer into infrastructure. If two teams define “revenue” differently and the conflict is not resolved, the system silently picks whichever version was codified and serves it as organizational truth.

Weak benchmark selection

Teams validate against easy, uncontested questions and declare success. The real test is whether the system handles the high-value, edge-case-ridden, business-critical questions analysts actually answer. If your benchmark suite does not include the hard questions, you have not tested the system.

Skipping metadata enrichment

Generic comments force the AI to guess at field meanings. At scale, guessing means wrong answers delivered to users who have no way to know the AI was uncertain.

Compensating with instructions instead of examples

Both platforms benefit far more from well-written example queries than from text instructions. Instructions produce diminishing returns.

No designated owner

Without an owner, maintenance becomes nobody’s job. Accuracy erodes. Because the AI does not signal uncertainty, no one notices until business decisions have been made on bad answers.

The work is usually more bounded than teams fear, but heavier than they expect.

Phase-Level Rollup

Effort by Work Category

Each role exists to prevent a specific category of failure. This is a control system, not a staffing list.

Hours assume favorable conditions. If metric conflict is significant, BI/Semantic Owner and Business SME hours expand most.

Focus on a single domain, small table set, well-understood metrics. Validate the workflow and establish maintenance before expanding.

Both platforms assume you have already defined your metrics, agreed on business logic, and documented how analysts translate questions into SQL. Neither extracts institutional knowledge automatically. Neither resolves ambiguity. Neither flags that a codified definition was contested.

The kinds of buried institutional logic that must be surfaced before implementation:

• Preferred join paths: which tables to join and in what order, learned through years of trial and error
• Exception handling: nulls, edge cases, partial records, known data quality issues
• Exclusion logic: records, statuses, or source tables filtered out by default
• Trusted vs. distrusted tables: which tables analysts actually use vs. avoid, and why
• Time-period conventions: fiscal vs. calendar year, trailing periods, default lookback windows
• Default filters: standard WHERE clauses applied without thinking (excluding test accounts, internal transactions)
• Business-safe interpretation patterns: handling ambiguous questions in ways the business considers acceptable

The system can be technically deployable long before it is safe to trust broadly.

Data Foundation (Technical)

• ☐ Source tables identified and accessible in the target platform
• ☐ Star schema or denormalized views available (or plan to create them)
• ☐ Primary and foreign keys defined and validated
• ☐ Column data types appropriate (no implicit conversions needed)

Business Logic (Semantic + Institutional)

• ☐ Core metrics defined with agreed-upon aggregation formulas
• ☐ Metric conflicts identified and resolved (or explicitly scoped with documented rationale)
• ☐ 10+ benchmark questions written, including 3-4 hard, contested, or edge-case questions
• ☐ The people who define or approve the metrics have signed off on what gets codified
• ☐ Preferred join paths, exclusion logic, and default filters documented

Ownership (Institutional)

• ☐ Semantic owner assigned (SQL + business context hybrid role)
• ☐ Weekly maintenance cadence committed
• ☐ Version control and CI/CD pipeline planned
• ☐ Feedback review process defined
• ☐ Organization understands that codified definitions will be served as truth at scale

Governance (All Three)

• ☐ RBAC roles identified for semantic layer consumers
• ☐ Masking / row access policies defined at the physical table level
• ☐ Go-live testing plan includes per-role privilege validation
• ☐ Plan exists for detecting and correcting wrong answers post-deployment