databrickssqlvisualization Resource

June 12, 2026 · View on GitHub

API Documentation

!> This resource is deprecated and will be removed in future.

-> Please switch to databricks_dashboard to author new AI/BI dashboards using the latest tooling

To manage SQLA resources you must have databricks_sql_access on your databricks_group or databricks_user.

-> documentation for this resource is a work in progress.

A visualization is always tied to a query. Every query may have one or more visualizations.

Example Usage

resource "databricks_sql_visualization" "q1v1" {
  query_id    = databricks_sql_query.q1.id
  type        = "table"
  name        = "My Table"
  description = "Some Description"

  // The options encoded in this field are passed verbatim to the SQLA API.
  options = jsonencode(
    {
      "itemsPerPage" : 25,
      "columns" : [
        {
          "name" : "p1",
          "type" : "string"
          "title" : "Parameter 1",
          "displayAs" : "string",
        },
        {
          "name" : "p2",
          "type" : "string"
          "title" : "Parameter 2",
          "displayAs" : "link",
          "highlightLinks" : true,
        }
      ]
    }
  )
}

Separating visualization definition from IAC configuration

Since options field contains the full JSON encoded string definition of how to render a visualization for the backend API - sql/api/visualizations, they can get quite verbose.

If you have lots of visualizations to declare, it might be cleaner to separate the options field and store them as separate .json files to be referenced.

Example

  • directory tree

    .
├── q1vx.tf
└── visualizations
    ├── q1v1.json
    └── q1v2.json

  • resource definitions

    ##q1vx.tf

resource "databricks_sql_visualization" "q1v1" {
  query_id    = databricks_sql_query.q1.id
  type        = "table"
  name        = "My Table"
  description = "Some Description"
  options     = file("${path.module}/visualizations/q1v1.json")
}

resource "databricks_sql_visualization" "q1v2" {
  query_id    = databricks_sql_query.q1.id
  type        = "chart"
  name        = "My Chart"
  description = "Some Description"
  options     = file("${path.module}/visualizations/q1v2.json")
}

Argument Reference

  • provider_config - (Optional) Configure the provider for management through account provider. This block consists of the following fields:
    • workspace_id - (Required) Workspace ID which the resource belongs to. This workspace must be part of the account which the provider is configured with.

Known Issues

As of 2022-09, databricks sql visualization backend API does not validate the content of what is passed via options, couple that with options being outputted as string in the module, it can lead to configurations which succeed terraform plan but do fail at terraform apply.

In some instances, incorrect definitions within options can lead to stuck terraform states. In preparation for this operational scenario; you should be familiar with, and have sufficient access for, manual inspection and modification of your deployed terraform state.

Import

You can import a databricks_sql_visualization resource with ID like the following:

import {
  to = databricks_sql_visualization.this
  id = "<query-id>/<visualization-id>"
}

Alternatively, when using terraform version 1.4 or earlier, import using the terraform import command:

terraform import databricks_sql_visualization.this <query-id>/<visualization-id>

The following resources are often used in the same context: