Skip to content

future-native-resource.md

Latest commit

 

History

History
56 lines (46 loc) · 2.68 KB

future-native-resource.md

File metadata and controls

56 lines (46 loc) · 2.68 KB
Raw

Future: native genie_spaces DAB resource

Today this repo promotes Genie Spaces by driving the Genie SDK from a job (the export -> transform -> deploy pattern). That is the supported, production-ready approach as of mid-2026.

There is also active work to make a Genie Space a first-class bundle resource, so you could declare it directly in databricks.yml the same way you declare a job or a pipeline. When that lands, the YAML would look like this:

resources:
  genie_spaces:
    sales_assistant:
      title: "Sales Assistant"
      description: "Ask questions about sales data"
      warehouse_id: ${var.warehouse_id}
      parent_path: /Workspace/genie-spaces/${bundle.target}
      serialized_space: ${file("spaces/sales_assistant.json")}  # the serialized blob
      permissions:
        - level: CAN_VIEW
          group_name: data-analysts

databricks bundle deploy would then create/update/delete the space as part of the normal bundle lifecycle, no job required.

Status and caveats (verify before relying on this)

  • Not GA. As of mid-2026 the native genie_spaces resource is not in the shipped, supported bundle resource list. Treat the snippet above as forward-looking, not something to put in a production pipeline yet.
  • Direct-deploy only (as proposed). The in-flight implementation targets the bundle "direct" engine (DATABRICKS_BUNDLE_ENGINE=direct databricks bundle deploy). Terraform mode is not supported because the Databricks Terraform provider does not yet expose a databricks_genie_space resource. If your org standardizes on the Terraform deploy path, this won't fit until the provider catches up.
  • The serialized_space blob is still the source of truth. Even with the native resource, the space's content is the same serialized JSON you manage today. So the export/transform workflow in this repo is not throwaway: it is how you produce and environment-parameterize that blob either way.

Recommendation

Build on the job-based approach in this repo now. When the native resource goes GA, migrating is mostly mechanical: move the serialized_space artifact into a resources.genie_spaces block and drop the deploy job. The hard part (managing and parameterizing the serialized definition) is identical across both.

References