Genie space: Delta Tables or Metric View
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-23-2026 10:24 AM
I have started experimenting with Genie Spaces.
I have a delta table with sales information. It has a date column, customer, product and amount bought.
My question is, is it better to point the genie space to the raw table or create a metric view with all the possible measures someone might ask? Considering this will also be enriched in the future with more data.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-23-2026 12:52 PM
Hi @Andrewww, it is fantastic to see you exploring Databricks Genie Spaces! Since you are currently in the initial experimentation phase and working with a streamlined sales dataset, starting by pointing Genie directly to your raw table is completely fine for a proof of concept.
However, as your data grows and you add more details, pointing Genie directly to raw data will cause friction. Think of Genie as a super smart intern. If you give it a messy, raw table, it will waste a lot of time guessing what the columns mean and might make mistakes.
Leaving the raw setup as-is simply forces Genie to expend extra compute resources and processing time on basic logic:
- Extra Logic Processing: If a user asks for "total sales," Genie has to write more complex, multi-step SQL queries on the fly to deduce whether to sum the raw amount column or filter out cancelled orders first.
- Slow Answers: Querying raw rows forces Genie to scan every single record for every question, meaning your users wait longer for answers.
- Complex Join Computations: As you add more tables later, Genie will have to dynamically compute table relationships and keys for every session, which adds computational overhead compared to reading a pre-governed view.
Creating a clean, pre-modeled metric view changes everything because it gives Genie a clear map to follow. You can lock your business math such as excluding cancelled orders, directly inside the view. Genie just reads it, ensuring everyone gets the exact same answers with much better performance.
To scale this smoothly, think of your data as a production line that refines raw data into high-quality answers:
- Bronze Layer: This holds your raw, unedited sales entries, which are great for storage but too noisy for Genie.
- Silver Layer: This cleans up your records, strips out processing errors, and standardizes dates.
- Gold Layer: This is your highly polished semantic view built on top of that clean data, holding your official business metrics. This is the absolute best place to point Genie.
To get started with this setup, the official documentation recommends keeping your space focused on one small business topic at first. You should also give Genie a benchmarking cheat sheet of 5 to 10 example questions your team will actually ask to track accuracy.
Your biggest quick win right now is configuring your metadata to speak plain English:
- Use Clear Synonyms: Map business terms or shorthand like "Revenue" or "Spend" directly to your table's columns.
- Add Field Descriptions: Write simple, clear comments on your columns in Databricks. Genie reads these comments natively, which instantly stops the guessing game and ensures highly accurate answers.
For a deeper dive into these optimization strategies, you can read the full Databricks AI/BI Genie Best Practices Guide.
Happy experimenting, and enjoy building out your space!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-23-2026 01:06 PM
Thanks for the reply! Very useful.
If i add both the metric view and the raw table will this confuse the genie space? Or is it ok?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-23-2026 08:03 PM
Adding both the raw Delta table and the Metric View generally causes confusions to the Space. Genie relies entirely on the schemas, descriptions and metadata you provide to translate queries into optimized SQL. If you expose both objects containing the same underlying data it introduces evere semantic ambiguities (2 path dilemma) where Genie has to guess whether to write an on the run un-governed calculation against the raw columns or leverage the defined semantic logic in metric view. It can drastically increase overhead and heavily opens the door for errors and inefficiencies.
You can hide the raw and silver layer tables from the Genie Space configuration entirely (after testing via raw tables intially) and expose the curated Metric View later. You can establish a strict single source of truth by defining the dimensions, relationships and business measures (total slippage) inside a Metric View. You can add the tables to the space if you have separate, completely non overlapping dimension tables that aren't integrated into that Metric View. Just ensure that there is zero structural or logical overlap with the primary fact data.
You can keep the model focused ideally aiming for fewer than 15 objects per space to maximize efficiency. Restricting Genie's scope to just your governed Metric Views ensures that the underlying model doesn't get distracted by redundant schemas or competing definitions. It guarantees significantly higher accuracy, lower consumption and completely reliable deterministic generation for users