slashpeak
Product

Reservations

Slot and reservation right-sizing: slot use vs what you pay for, idle slot cost, contention, and who uses the slots. On the 30-day trial, Pro and Enterprise.

The Reservations page (/reservations) is for teams on BigQuery Editions (capacity pricing) or legacy flat-rate. It shows how busy each reservation is, hour by hour, and where you pay for slots you do not use.

Plans

PlanReservations page
30-day trialYes
StarterNo
GrowthNo
ProYes
EnterpriseYes

On Starter and Growth the page shows a lock. Reservation findings stay on the Findings page on every plan. You still see under-used reservations, contention and pricing-model advice there.

What you need

  • The BigQuery Reservation API enabled. See Enable Google APIs.
  • bigquery.reservations.list in the scanner role, plus bigquery.capacityCommitments.list and bigquery.reservationAssignments.list in the optional role. Setup lists them under Slot reservations on the Optional access step.
  • The scanner role bound on the reservation admin project too.

Why the admin project matters

Reservations, assignments and commitments often live on a separate billing or admin project, not on each data project. Bind the scanner role there too, or this page under-counts.

If every job in the window ran on-demand, the page says so. Slot charts start once a reservation is assigned.

The page, top to bottom

Pick a reservation and a period at the top. Every section follows them.

Capacity

Tiles:

  • Reservations: how many, and in how many regions.
  • Avg slots used of the slots assigned, and the p95 utilization.
  • Idle slot cost: what the unused baseline slots cost per month, at the region's list price.
  • On-demand jobs and Reservation jobs: the split of jobs and spend.

Chart tabs:

TabShows
Assigned vs consumedSlots you pay for vs slots your jobs used, per hour
AutoscaleAutoscale slots in use vs the autoscale maximum
Slot-hoursSlot-hours used each hour, with the busiest minute's job count
ContentionSeconds jobs waited for a slot, with the number of jobs running at once
BillingOn-demand vs reservation jobs
ToolSlot-hours by tool (dbt, Looker, scheduled query and so on)

Hourly utilization heatmap

Hour of day × day, in your account timezone. The color is slots consumed ÷ slots assigned:

Color bandMeaning
Below 40%Paid-for slots sit idle. A candidate to shrink
40–80%Healthy
80–95%Busy
95% and upAt the ceiling. Jobs may wait

Reservations

Every reservation seen in the window: region, edition, jobs, estimated cost, average assigned and consumed slots, p95 utilization, and idle cost per month. Click a row to focus the page on it.

Who uses the slots

Slot-hours for the selected reservation by identity (user or service account) and by dataset.

Capacity findings

Open reservation and pricing-model findings for the selected reservation:

FindingDollar estimate?
Under-utilized reservationYes, from the unused baseline
Slot contentionNo (advisory)
Compute pricing model (on-demand vs capacity)Yes. See Pricing model by workload
dbt model pricing modelYes
Service account pricing modelYes

Click Open in Findings to see the full finding.

Pricing model by workload

What each project, user, dbt model and query cost in the selected period: now, on on-demand (bytes billed × $/TiB) and on slots (slot-hours × the edition's pay-as-you-go price, plus 20% for autoscale's 1-minute minimum and 50-slot steps). The cheaper side is in bold. Could save shows only when the cheaper side is at least 20% cheaper.

Above the table, Saving by routing method shows what each way of choosing a model would save over the period, each with one choice per group: whole project, project by time of day, service account, dbt model, and every query on its own. Under it, one line says how much routing each query on its own would add over the best method. Routing single queries needs code in your query path; when it adds under 3% of compute, the line says the best method already gets almost all of it.

This table does not count free idle baseline, so moving work onto a reservation can cost less than it shows. The Compute pricing model finding does count it, project by project:

  • On-demand project, a reservation in its region: it prices the move minute by minute. Work that fits in the reservation's idle baseline costs nothing extra. The rest is priced as autoscale, plus 20%. If the reservation also serves projects SlashPeak does not scan, all the work is priced as autoscale. It skips a reservation that would hit its max slots in more than 1% of the project's minutes.

  • Project on a reservation: moving to on-demand saves only the autoscale the project used. The baseline stays paid.

  • On-demand project, no reservation it fits on: advice on what to create: the edition, a slot commitment sized to the slots used almost all day (also the baseline), and max slots at the busiest normal minute. SlashPeak never creates a reservation or buys a commitment.

  • Time-of-day schedule: when the project's busy hours are cheaper on the reservation and its quiet hours on on-demand, the finding offers a daily schedule instead: one 24-hour UTC pattern for weekdays and one for weekends, blocks of at least 2 hours, at most 4 changes a day. It replaces the single move only when it saves at least 10% of the current bill more than the best single model.

A project gets this finding only when at least 90% of its work runs on one model.

Two finer findings cover work inside a project whose project stays where it is:

  • dbt model pricing model: one dbt table or incremental model whose own runs are clearly cheaper on the other model. The fix is one sql_header line in the model: SET @@reservation = '…' (or 'none' for on-demand).
  • Service account pricing model: one service account whose own queries are clearly cheaper on the other model. The fix is a reservation assignment for just that account.

Both price an on-demand workload as new autoscale plus 20% on the cheapest edition in the region (no idle-baseline credit), and a reservation workload by its share of that reservation's autoscale. Neither shows when the project finding already moves the whole project the same way.

Configuration

Snapshots from the reservation admin project:

  • Reservation assignments: which project, folder or organization uses which reservation, and for which job type.
  • Capacity commitments: plan, state and slots.

Make the change

SlashPeak never changes a reservation by itself. Ways to act:

  • Change it yourself in the Google Cloud console.
  • On Growth and up, use the AI DBA action Resize reservation. It lowers the baseline slots, never below the p95 of slots used, by at most half per step, in steps of 50 slots. It always needs an owner's approval, and it can be undone. Autoscale is not touched. See Cognis AI DBA.
  • On Growth and up, use the AI DBA action Move project to the cheaper pricing model on a Compute pricing model finding. It changes the project's QUERY reservation assignment in the reservation's admin project: onto an existing reservation, or to on-demand. It always needs an owner's approval and can be undone. It waits 14 days between moves of one project, and puts the old assignment back by itself if the project's p95 query time doubles. For a time-of-day schedule you approve the schedule once; the AI DBA then moves the project 5 minutes before each block until you undo it. If someone changes the assignment by hand, the schedule stops and leaves their change.
  • On Growth and up, a dbt model pricing model finding becomes a pull request that adds the sql_header line to the model. A person merges it. The account that runs dbt needs bigquery.reservations.use on the reservation.
  • For a service account pricing model finding, create the assignment for that account in the reservation's admin project. Google calls these principal assignments Preview, so the AI DBA does not make them yet.

How capacity cost is priced

Each capacity job is priced at slot-hours × the pay-as-you-go rate of its reservation's edition. If the edition is unknown, the Enterprise edition rate is used. See How scans work.

On this page