The problem: cost data is separated from the decision
Engineers choose cluster types, schedule jobs and change workloads. They can make a change that increases spend today, then see its cost only weeks later in a report owned by a small FinOps or platform team. By then, the person closest to the workload has lost the context needed to act quickly.
Opening Databricks cost data to engineers can feel risky. Cost tables are useful, but they have often been treated as restricted because query history can contain the full text of SQL statements. That text may include sensitive values or personal data.
Without visibility
Cost is someone else's reportWorkload owners cannot connect a cluster, job or schedule change with the resulting spend.
With safe visibility
Cost becomes a team signalEngineers see the impact, investigate patterns and fix the resource they own.
What changed
On August 26, 2026, Databricks changed the default handling of statement_text in system.query.history. Standard users see the field masked as <REDACTED>. Full query text remains available only to account administrators and users in the designated databricks_pii_access group.
This removes a major barrier to sharing cost signals more broadly. Engineers can work with usage and cost data without automatically receiving the SQL text behind every query.
Why transparency changes behaviour
Cost data is most valuable to the people who select cluster types, schedule jobs and write workloads. When teams can compare their compute use, they can spot idle resources, outdated schedules and patterns that deserve a second look.
Transparency can also turn cost review into knowledge sharing. A team that sees an expensive but avoidable configuration can use it as a practical example for everyone else. The point is not to rank people. It is to connect day-to-day technical decisions with their cost.
The result: faster, shared cost improvement
A broader cost view does not replace FinOps. It gives the FinOps and platform teams more people who can detect and resolve waste. An owner can see an idle cluster, an old schedule or an unusual increase in spend and address it while the workload is still familiar.
The result is a shorter path from a cost signal to a technical change. Teams learn from one another's configurations, while the central team can focus on exceptions, guardrails and the work that needs broader coordination.
Share the right data
Give teams access to
Cost and usage signalsCluster cost, job cost, runtime, ownership and trends that support action.
Keep restricted
Full query textUse the dedicated access group when someone needs to investigate the SQL itself.
Start with views that answer clear questions: Which clusters are still running, which scheduled jobs cost the most and where did spend change from the previous period. Keep the raw detail available to the people who need it, while giving everyone else a safe path to understand their impact.
A practical next step
- Confirm that query text is masked for standard users in your workspace.
- Define who needs membership in the query text access group.
- Publish a small cost view for engineers and workload owners.
- Review the questions teams ask, then improve the view around those decisions.
Engineers cannot manage a cost they cannot see. With query text protected by default, cost visibility can be part of normal platform work instead of a report reserved for a small group.