Feature request: first-class hook to attach BigQuery job labels to generated queries

[darrenjl]

Problem

When Cube executes queries against BigQuery, there is currently no supported way to attach BigQuery job labels to the underlying jobs. Job labels appear in INFORMATION_SCHEMA.JOBS.labels and are the standard mechanism for attributing query cost and usage back to an application, user, or request.

Without labels, the only way to correlate a Cube request with a BigQuery job is via timestamp matching — fragile and imprecise under concurrent load.

This was raised previously in #7753, where the reporter found a workaround by subclassing BigQueryDriver and reading requestId from the options parameter passed to query(). That workaround works but requires maintaining a custom driver subclass and is not documented or officially supported.

Use Case

Teams running Cube on BigQuery often want to attribute query cost and usage back to individual users, tenants, or upstream requests for observability and chargeback purposes. BigQuery job labels are the standard way to do this — they appear in INFORMATION_SCHEMA.JOBS.labels and can be used to slice cost and usage data.

This requires labels to be dynamic per request — derived from context available at query time such as the security context, request ID, or custom headers — not statically configured at server startup. For example:

SELECT * FROM `region-eu.INFORMATION_SCHEMA.JOBS`
WHERE labels['user_id'] = '123'
  AND labels['tenant'] = 'acme'

Proposed Solution

A new configuration hook — queryLabels or similar — that receives per-request context and returns a flat key-value map to attach as labels on the outgoing BigQuery job:

// cube.js
module.exports = {
  queryLabels: ({ securityContext, requestId }) => ({
    user_id: securityContext.userId,
    tenant: securityContext.tenantId,
    request_id: requestId,
  }),
};

The hook should receive at minimum:

• securityContext — the resolved security context for the request
• requestId — Cube's internal request ID

This would be BigQuery-specific initially but could generalise to other drivers that support query tagging (e.g. Snowflake query tags, Redshift query groups).

Alternatives Considered

• Subclassing BigQueryDriver (current workaround from Support for BigQuery labels #7753) — works but requires custom driver maintenance and deep knowledge of driver internals
• SQL comments — queryRewrite operates at the Cube DSL level, not raw SQL, so injecting /* request_id=... */ comments is not possible without patching the driver
• Timestamp correlation — works but is imprecise under concurrent load

References

• Support for BigQuery labels #7753 — prior issue, closed with a DIY workaround rather than native support
• BigQuery job labels docs
• INFORMATION_SCHEMA.JOBS

[darrenjl]

Following up on #7753 (opened Feb 2024, closed without resolution) — this is an ongoing gap that affects anyone doing multi-tenant cost attribution on BigQuery.

The use case: in a multi-tenant SaaS context, every query Cube generates hits BigQuery as the same service account. Without job labels, there's no reliable way to break down costs by tenant, user, or request type via INFORMATION_SCHEMA.JOBS. The current workarounds (driver subclassing, timestamp correlation) are fragile and unsupported across upgrades.

The proposed queryLabels hook mirrors patterns already common in other query middleware (e.g. Prisma's $extends query hooks, Apollo Server's context). It would be a low-touch, non-breaking addition to the BigQuery driver.

Would love to see this triaged. Happy to contribute a PR if the core team can confirm the right integration point (likely buildQueryPayload in cubejs-bigquery-driver).

[Korg95]

Similar to bigquery we would like to set settings in clickhouse to set the log_comment setting which is the label on that platform #8838