Genie on raw Delta tables or metric views? What actually works

A question on the Databricks Community forum captures a decision every Genie rollout hits early. The poster had a simple Delta table (date, customer, product, amount) and wanted to know whether Genie should query that table directly, or a metric view that defines the measures users are likely to ask about. More data was coming, so they wanted the choice that would hold up.

The replies disagreed in an instructive way, so it’s worth walking through.

The short answer

For a proof of concept, a raw table is fine. For anything people will rely on, put the business logic in a metric view and make that the main thing Genie sees. Then test whether also exposing the raw table helps or hurts, with benchmarks rather than opinion.

Why raw tables run out of road

With only a raw table, Genie has to infer what every column means and rebuild every calculation from scratch each time someone asks. “Revenue” becomes whatever SQL it writes for that question: maybe SUM(amount), maybe with returns excluded, maybe not. Two users asking the same question in different words can get two different numbers, and both look confident.

That’s manageable with one clean table and simple questions. It gets worse as you add tables, because every extra table is another join Genie can get wrong and another place a similar-looking column can be picked by mistake.

What metric views change

Unity Catalog metric views let you define a measure once, separately from the dimensions it’s grouped and filtered by. “Revenue”, “active customers” or “average order value” get written down a single time with their business rules, and any query, from a notebook, a dashboard or Genie, uses that definition.

For Genie this matters in three ways:

• One definition per metric. Genie stops reinventing your KPIs per question. It picks the governed measure instead of improvising.
• Simpler SQL. Joins and calculations live in the metric view, so the SQL Genie writes is shorter and has fewer places to go wrong.
• Fewer objects in the space. A metric view can stand in for several tables. Databricks’ Genie best practices say metric views are “particularly effective” for Genie for exactly this reason. The same page caps a Genie Agent at 50 tables, views or metric views, but recommends aiming for five or fewer.

Metric views can also carry agent metadata like synonyms and display names, and they support materialization, so pre-computed aggregations can be refreshed incrementally as data grows. That speaks directly to the forum poster’s worry about volume.

Should you include both?

This is where the thread split.

One reply argued that exposing both the raw table and the metric view confuses Genie. It can choose between an ungoverned calculation on raw columns and the governed measure, and you won’t always know which one it picked. Their advice was to test on raw tables first, then hide the raw and intermediate tables and expose only the curated metric view.

Another practitioner shared an experiment on their own delivery data that pointed the other way. With raw tables and metric views together, Genie got 36 of 36 benchmark questions right. With metric views only it got 34, and with raw tables only 29.

Both can be true. Metric views answer the questions their measures were designed for. Questions outside those measures (a one-off breakdown by a column nobody modeled, a row-level lookup) need something underneath. Whether the raw table helps or confuses depends on how much your users’ questions stray from the measures you defined, and on how clearly the instructions tell Genie which to prefer.

That’s not a question to settle by debate. It’s what benchmarks are for.

How we’d set it up

1. Model the gold layer first. Point Genie at clean, purpose-built tables, not the raw ingestion layer. If the data needs fixing, fix it before Genie sees it.
2. Define the top measures as a metric view. Start with the five to ten numbers people actually ask about, with the business rules written into the measure, not into instructions.
3. Write a benchmark set. Collect real questions from the people who’ll use the space, each with an answer an analyst agrees is correct. Genie lets you save reviewed questions as benchmarks and score the space against them.
4. Run it three ways. Metric view only, raw tables only, and both together. Keep whichever scores best on your questions.
5. If you keep both, tell Genie which comes first. Use the instructions to say that governed measures come from the metric view, and hide raw columns that duplicate a measure. Add example SQL for the questions that need the raw table.
6. Keep the space small and focused. One domain per space. Add objects a few at a time and re-run the benchmarks every time.

The bigger lesson

The forum thread is a good example of why Genie advice needs testing rather than adopting. Two experienced answers gave opposite recommendations, and each was right for its own data. What made the second answer useful was a number: 29, 34 and 36 out of 36. That’s the habit to copy. Before deciding how to structure a Genie space, decide how you’ll measure it.

Summary

• Raw tables are fine for a proof of concept and fragile in production.
• Metric views give Genie one governed definition per measure, simpler SQL and fewer objects to choose from.
• Whether to also expose raw tables depends on your users’ questions. Benchmark both setups and keep the winner.
• Model the gold layer first, start with the top measures, and keep each space to a handful of objects.

If you’re deciding how to model data for Genie and want help with the metric views, benchmarks or rollout, see our Databricks Genie implementation page.