Query text access in Databricks
What Databricks's SQL query text masking change affects in Atlan, what it doesn't affect, and how to keep query-text features running.
Databricks now masks the SQL text of queries in query history by default. Your lineage graph and catalog aren't affected, and one scoped grant keeps everything else running as it does today.
What stops updating for me in Atlan?
Databricks now masks the statement_text column in system.query.history by default. Since Atlan reads query history to surface SQL detail, four capabilities stop updating until access is restored:
- Usage and popularity metrics, including column popularity
- SQL detail in lineage: the statement behind an edge and its joins
- Queries shown on asset profiles
- SQL Intelligence in Context Agents Studio, which enriches assets from query logs
Historical data is preserved; only queries run after the masking change are missing. Table-level and column-level lineage, asset discovery, metadata, tags, classifications, contracts, and glossary aren't affected—those come from Unity Catalog system tables, which are a separate source unrelated to query text.
What has Databricks changed?
The statement_text column in system.query.history is now masked by default. Only account admins and members of the account-level group databricks_pii_access can read it. Every other identity sees <Redacted>. This is a Databricks platform change. It applies to every tool that reads query history, not only Atlan.
When does it reach my account?
The rollout began on June 22, 2026 and becomes the default for all accounts on August 26, 2026. It's staged, so timing varies by account. Access granted ahead of your rollout means you won't notice the change at all.
Did Atlan cause this?
No. This is a Databricks platform change that affects every system reading query history. Restoring query text requires a one-time change by your Databricks account admin - see Grant query text access for Databricks.
What does Atlan read from query history?
The shape of queries, not the data inside your tables. This is the entire scope, and the grant doesn't change it.
| Atlan reads | Atlan doesn't read |
|---|---|
The SQL text of queries, who ran them and when, from system.query.history only | The contents of your tables. No table data is copied as part of this grant. |
| The tables and columns each query touched, to compute usage and popularity and enrich lineage with the underlying SQL | Any other system table, workspace object, or catalog the service principal couldn't already read. |
Atlan doesn't need the personal data that can appear inside a query. It reads the structure of the statement.
How do I check where my connection stands?
Run this as the same service principal your Atlan connection uses. Masking depends on who is reading, so a Databricks account admin always sees query text even when Atlan can't.
SELECT COUNT(*) AS queries_checked,
SUM(CASE WHEN statement_text = '<Redacted>' THEN 1 ELSE 0 END) AS redacted,
SUM(CASE WHEN TRIM(statement_text) = '' THEN 1 ELSE 0 END) AS empty
FROM system.query.history
WHERE start_time >= current_timestamp() - INTERVAL 7 DAYS;
Each number is a count of queries in the window.
| Query result | What it means | What happens next |
|---|---|---|
redacted and empty are 0 | Atlan can read query text | Nothing is needed today. Re-run this check if usage metrics stop updating. |
redacted isn't 0 | Query text is masked | Query text is masked for Atlan. See Grant query text access for Databricks to restore it. |
empty isn't 0 | Query text is encrypted, not masked | This comes from customer-managed keys and predates this change. See Does this affect me if I use customer-managed keys?. The grant doesn't resolve it. |
queries_checked is 0 | No queries in the window, so the check can't tell you anything | Increase the number of days in the query and run it again. |
Only queries on SQL warehouses and serverless compute appear in this table, so queries_checked can stay at 0 if your workloads run on classic clusters. If you can't run this yourself, your Atlan administrator or Atlan support can confirm where your connection stands.
How do I keep everything running?
One account-level grant restores access: your Databricks account admin adds Atlan's service principal to the account group databricks_pii_access, creating the group if it doesn't exist. One grant covers every workspace in the account, and your lineage graph is unaffected throughout. For the full steps, including how to confirm it worked, see Grant query text access for Databricks.
Does this affect me if I use customer-managed keys?
No. Where a workspace uses customer-managed keys for managed services, Databricks encrypts statement_text in system tables so it returns empty. That behavior predates this change and is unrelated to it, so this change makes no difference to you. Adding Atlan's service principal to databricks_pii_access won't restore query text either, because it was never masked in the first place.
Restoring it's a separate action: an account admin adds a key configuration to the system catalog. Reach out to Atlan support and they'll confirm what Atlan is seeing on your connection before you change anything.
See also
- Extract lineage and usage from Databricks: Configure lineage and usage extraction for your Databricks connection.
- Atlan vs. Databricks lineage: How Atlan lineage differs from Databricks native lineage and what each system shows.
- Usage and popularity metrics: How Atlan computes and displays usage and popularity scores.