How BigQuery actually runs your query.

What a job actually is

Every query, load, export, or copy operation in BigQuery is represented as a job with its own ID, status, and lifecycle: pending, running, then done or failed. When you submit SQL, BigQuery doesn't execute it synchronously and hand back rows in the same breath. It creates a job, queues it against available query slots, runs it, and only then makes results available. A client asks "is this job done yet" repeatedly, called polling, until the answer is yes.

This is different from a typical database connection, where a query blocks the connection until it returns. BigQuery's job model exists because queries can take anywhere from milliseconds to tens of minutes, and a request/response model that just hangs for that whole window doesn't fit BigQuery's scale or its separation of storage from compute.

Why this matters practically

A few things fall out of the job model directly. First, every query has a job ID you can look up later, in the Cloud Console or through the API, even after the client that submitted it has moved on. Second, retries are a first-class concept: a client can safely retry checking a job's status without accidentally running the query twice, because checking status and submitting a new job are different API calls. Third, a job's results can, in some cases, be reused later without re-running the query, if BigQuery's cache still has them.

How this shows up in QueryFlow

When you run a query in QueryFlow against a BigQuery connection, the app submits it as a job and polls until it completes, the same underlying mechanism the Cloud Console and the bq CLI use. You don't see the polling directly, the query just appears to run and return results, but it's why a long-running query shows a progress state rather than a frozen window: QueryFlow is checking in periodically, not holding a connection open and hoping.

-- A job-backed query, same as any other
SELECT DATE(event_time) AS day, COUNT(*) AS events
FROM `my-gcp-project.logs.raw_events`
WHERE DATE(event_time) = CURRENT_DATE()
GROUP BY day;

Whether that query takes 200 milliseconds or two minutes, the mechanism underneath is identical: a job, polled to completion, results fetched once it's done.

Where it shows up elsewhere

A scheduled query in QueryFlow works the same way at a larger interval, it's a job submitted on a schedule rather than by a click. Watch This checks a result on its own schedule by re-running the underlying query as a fresh job each time. None of this requires you to think about the Jobs API directly, but it explains why a "run" in BigQuery tooling always has a status, a history, and sometimes a delay before results land, rather than an instant response.

A quick mental model

Think of it less like calling a function and more like submitting a work order: you get a ticket number back immediately, the actual work happens on its own schedule, and you check back for the result. That's the entire mental model, and it explains most of the behavior that otherwise looks surprising, why a query "runs" even after you've closed the tab that submitted it, why job history persists independently of any one client, and why a slow query doesn't hang your connection, it just takes longer to report done.

Where to see it yourself

The Cloud Console's Job History page lists every job on a project, including ones submitted by other tools, with their status and duration. It's a useful place to look when a query feels slower than expected and you want to confirm whether the delay was queuing time or actual execution time.