13.4 Query Workload Management: Interactive vs. Batch Jobs, Queues, and Quotas
Key Takeaways
- BigQuery query jobs default to INTERACTIVE priority; BATCH priority queries are more likely to be queued when resources are saturated but run identically once execution starts, and they do not count toward the concurrent query rate limit.
- Up to 1,000 interactive and 20,000 batch queries can be queued per project per region, these limits cannot be increased, and queued jobs time out after 6 hours for interactive and 24 hours for batch by default.
- Setting a queue timeout to -1 with ALTER PROJECT SET OPTIONS disables queuing so excess queries fail immediately with ADMISSION_DENIED instead of waiting.
- A reservation concurrency cap is applied only at query admission time, never cancels running queries, and can take up to a minute to take effect.
- Project-level custom daily quotas stop the entire project once exhausted, while user-level quotas contain a single heavy user, and INFORMATION_SCHEMA.JOBS plus the BigQuery admin panel are the surfaces for diagnosing workload problems.
13.4 Query Workload Management: Interactive vs. Batch Jobs, Queues, and Quotas
Sub-section 5.3 of the exam guide, Organizing workloads based on business requirements, has two bullets. The first — capacity management with BigQuery Editions and reservations — is covered in the preceding section. The second is "interactive or batch query jobs," and it is the one candidates most often skip because it looks like a single API flag. It is not. It is the mechanism by which a platform decides which work is allowed to wait, and it interlocks with query queues, concurrency targets, and quotas to form BigQuery's workload management story. Sub-section 5.4 then adds "manage workloads, such as jobs, queries, and compute capacity" and "troubleshooting error messages, billing issues, and quotas" on top of the same machinery.
Job Priority: The Cheapest Workload Control You Have
Every BigQuery query job carries a priority, and by default it is INTERACTIVE. Interactive jobs are intended to start executing as quickly as possible.
Setting priority to BATCH changes the scheduling contract:
- When a project or reservation is using all of its available compute resources, batch queries are more likely to be queued and to remain in the queue while interactive work goes first.
- Once a batch query begins executing, it runs exactly like an interactive query — same slots, same engine, same performance. Batch is a scheduling priority, not a slower execution mode.
- Batch priority does not count toward the concurrent query rate limit, so batch jobs do not consume the concurrency budget that interactive users depend on.
- When batch concurrency reaches its maximum, interactive queries are prioritized even if they were submitted later.
The decision rule is simply whether a human is waiting:
| Workload | Priority | Why |
|---|---|---|
| Dashboard and BI tool queries | INTERACTIVE | A person is staring at a loading spinner |
| Ad-hoc analyst exploration | INTERACTIVE | Same |
| Nightly ELT and table rebuilds | BATCH | Completion by morning is the only requirement |
| Multi-month historical backfill | BATCH | No deadline inside the hour; must not displace live users |
| Data-quality reconciliation jobs | BATCH | Runs on a schedule, results consumed later |
| Model training feature extraction | BATCH | Feeds a downstream job, not a person |
Priority is set with --batch on bq query, with configuration.query.priority in a jobs.insert request, or with the equivalent option in the client libraries.
Query Queues and Dynamic Concurrency
BigQuery automatically calculates how many queries can execute simultaneously based on available resources, and the number varies per project or reservation. Queries beyond that number are queued until capacity frees up, rather than being rejected.
The documented limits are precise and testable:
| Property | Interactive Queries | Batch Queries |
|---|---|---|
| Maximum queued per project per region | 1,000 | 20,000 |
| Default queue timeout before execution starts | 6 hours | 24 hours |
| Priority when batch concurrency is saturated | Prioritized, even if submitted later | Yields |
Queries submitted beyond the queue limits receive quota errors, and these queue-length limits cannot be increased. The timeouts can be adjusted with ALTER PROJECT SET OPTIONS, and setting a timeout to -1 disables queuing entirely, which changes the failure mode: instead of waiting, excess queries fail immediately with ADMISSION_DENIED. That is occasionally the right choice for a latency-sensitive service that would rather fail fast and shed load than accumulate a queue, but it is never the right default.
Reservation Scheduling Policies
Inside a reservation you can additionally cap how many queries a project is admitted to run concurrently. Two behaviors matter operationally:
- The concurrency cap is applied only at query admission time and does not cancel already-running queries. Lowering it below the number currently executing simply causes new queries to queue until enough running queries finish.
- Changes take up to one minute to apply, and adjusting a per-project maximum slot setting requires a new query to start before it takes effect. A scenario describing "we changed the setting and nothing happened immediately" is describing expected behavior, not a bug.
Guardrails: Failing Cheap Instead of Billing Expensive
Workload management is incomplete without cost guardrails, because an unbounded query is a workload problem before it is an invoice problem:
| Guardrail | What It Does | Best Used For |
|---|---|---|
maximum_bytes_billed | Query fails before execution if it would scan more than the limit | CI jobs, scheduled queries, AI-drafted SQL |
| Custom project-level daily quota | Caps total bytes processed per project per day | Development and sandbox projects |
| Custom user-level daily quota | Caps bytes processed per user per day | Large analyst populations sharing one project |
| Job timeout | Cancels a job that exceeds a wall-clock limit | Runaway exploratory queries |
require_partition_filter | Rejects queries that omit a partition predicate | Very large fact tables |
The distinction between the two custom quota levels is a favorite exam detail: a project-level quota stops the whole project once the daily budget is exhausted, which protects the budget but also stops everyone; a user-level quota contains a single heavy user without taking the shared project down with them.
Observing and Troubleshooting the Workload
Two surfaces do the work here, and the blueprint names one of them explicitly:
INFORMATION_SCHEMA.JOBSand its variants expose job state, priority, queue time, slot-milliseconds consumed, bytes processed, and error results. This is where you answer "which queries are pending," "who consumed the slots last night," and "what did that query cost."- The BigQuery admin panel and its resource charts visualize slot consumption, job concurrency, and reservation utilization over time, which is the fastest way to see whether a latency complaint is a capacity problem or a query problem.
| Symptom | Likely Cause | Action |
|---|---|---|
| Queries sit pending for minutes during business hours | Concurrency saturated by batch-shaped work running at interactive priority | Move the scheduled work to BATCH priority |
ADMISSION_DENIED errors appear suddenly | Queuing was disabled by setting a queue timeout to -1 | Restore a positive timeout, or add capacity |
| Quota error on submission, not execution | Queue length limit reached (1,000 interactive or 20,000 batch) | Reduce submission rate; these limits cannot be raised |
| A nightly job silently never ran | It exceeded the queue timeout before starting | Raise the timeout or give the workload its own reservation |
| One analyst's queries exhaust the daily budget | No per-user containment | Custom user-level daily quota |
| Changed the concurrency target; running queries unaffected | Expected — the cap applies at admission only | Wait for running queries to drain; allow up to a minute for the change |
Putting It Together
A well-organized BigQuery workload uses all three levers together rather than reaching for reservations alone:
- Priority separates work that can wait from work that cannot, and costs nothing to apply.
- Reservations and assignments guarantee capacity floors for the workloads that must not be starved, and are covered in the capacity-planning section.
- Quotas and byte limits bound the damage any single query or user can do.
A scenario that describes nightly ELT competing with a morning dashboard has a cheap answer available before anyone buys slots: run the ELT at BATCH priority. Only when a guaranteed capacity floor is genuinely required does the answer escalate to a dedicated reservation.
Exam Traps and Antipatterns Summary
| Scenario Cue | Wrong Answer | Correct Action |
|---|---|---|
| "Nightly backfill slows the morning dashboard" | Buy a larger Enterprise Plus reservation | Run the backfill at BATCH priority first; escalate to a reservation only if a capacity floor is required |
| "Batch queries run more slowly than interactive ones" | Switch everything to interactive | Once started, a batch query runs identically; only admission differs |
| "We need more than 1,000 queued interactive queries" | Request a quota increase | The queue-length limits cannot be increased; reduce submission rate or restructure the workload |
| "Lowering the concurrency target did not stop running queries" | Restart the reservation | The cap applies at admission time and never cancels running work |
| "A scheduled query never executed and produced no error" | Check the destination table permissions | It exceeded the queue timeout before starting execution |
| "One data scientist burned the monthly budget in a day" | Revoke their BigQuery access | Custom user-level daily quota, plus maximum_bytes_billed on shared jobs |
| "Latency-sensitive service should shed load rather than queue" | Leave defaults in place | Set the queue timeout to -1 so excess queries fail fast with ADMISSION_DENIED |
A media company runs a two-hour ELT rebuild and a 14-month historical backfill in BigQuery every night. Both frequently overrun into the 08:00 business window, where they compete with executive dashboards and analyst queries and cause visible dashboard latency. The company wants the cheapest effective remedy before considering additional capacity. What should it do first?
A platform team lowers the maximum concurrency target on a reservation from 50 to 20 during an incident, expecting immediate relief. Thirty-five queries continue running for several more minutes, and a configuration change made moments earlier appears to have had no effect. What is the correct interpretation?
A data platform receives a burst of automated query submissions from a misconfigured application and begins returning quota errors at submission time rather than queuing the work. Operations requests a quota increase for the interactive query queue. How should the data engineer respond?
You've completed this section
Continue exploring other exams