Query attribution

Thunderduck pushes eligible work down to the source engine instead of reading every row into DuckDB — see Query in place. Every statement it sends there starts with a comment:

-- Thunderduck Query. query_id: 2f1c4a1e-0b3a-4c5d-9e6f-112233445566, user_id: 9a8b7c6d-5e4f-4a3b-2c1d-0e9f8a7b6c5d
SELECT region, sum(amount)
FROM   ds.sales
WHERE  order_date >= DATE '2026-11-01'
GROUP  BY region

query_id is the run id shown in Query History (shortened there, with the full id on hover), and user_id is the Thunderduck user who submitted it. The line is an ordinary SQL comment, so the statement runs unchanged.

One Thunderduck query can send more than one statement — typically one per pushed-down table reference. They all carry the same query_id and user_id.

Finding it in the source engine

The comment travels in the statement text, so it lands wherever that engine keeps SQL:

For example, the last day of Thunderduck jobs in BigQuery:

SELECT job_id, creation_time, query
FROM   `region-us`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
WHERE  query LIKE '-- Thunderduck Query.%'
  AND  creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 1 DAY)
ORDER  BY creation_time DESC;

Filter the other way — NOT LIKE — to leave Thunderduck traffic out of a log review. The -- Thunderduck Query. prefix is the stable part; the ids after it differ per run.

Catalog probes

Metadata refreshes and credential checks run by Thunderduck itself are not user queries, so they have no query or user id. They carry the same prefix with the source instead:

-- Thunderduck Query. source: catalog probe

Use it to tell those apart from queries your team submitted.

What has no entry

Only statements that reach a source engine are tagged. A query answered wholly inside DuckDB — Iceberg tables, files in object storage, results joined locally — leaves nothing in BigQuery, PostgreSQL, MySQL, Oracle or SQL Server to find.