BigQuery flat-rate pricing ended on July 5, 2023. Every customer on flat-rate or flex slots was moved to BigQuery Editions, on-demand pricing went up 25 percent, and a great deal of advice written for the old model became wrong overnight. Three years later, plenty of Looker teams are still running the reservation they were migrated onto, with the settings the migration gave them, without ever having asked whether it fits how Looker actually queries. Here is what should have changed, and how to check whether it did.
Are you on the right edition, or on an edition at all?
Under Editions you choose Standard, Enterprise or Enterprise Plus per reservation, with a baseline of slots that is always on and a max the reservation can autoscale to. Each tier has a different per-slot-hour price and feature set. On-demand remains available and bills per TiB scanned.
The migration from flat-rate generally landed customers on Enterprise with a baseline equal to their old commitment. That is the right answer for some workloads and an expensive default for others:
- Mostly scheduled dashboards, overnight PDT builds, modest daytime interactive use: concurrency is spiky and brief. A low baseline (even zero) with a max sized for the morning peak costs far less than a flat baseline, because autoscaled slots bill only while used (in one-minute minimums).
- Heavy interactive exploration all day by many users: a meaningful baseline is cheaper than paying autoscale rates, and a one- or three-year commitment on that baseline is cheaper still.
- Small data, many queries: if your queries scan little data, on-demand is often cheapest of all, and the discipline it imposes (narrow columns, pruning) is healthy.
The data to decide is in INFORMATION_SCHEMA.JOBS_BY_PROJECT: sum total_bytes_billed for an on-demand estimate, and chart total_slot_ms per minute to see your real concurrency profile. Do the arithmetic for each option on three months of history. The answer changes as usage changes, so repeat it annually.
Measure slot utilization from Looker's query patterns
Looker is unusual among BigQuery clients: its workload is dominated by dashboards, which fire many moderately complex queries at once, and by schedules, which run whether anyone is watching. Both shape slot demand in ways that are easy to fix from Looker and hard to fix from BigQuery.
Join Looker's System Activity to BigQuery's job history. Looker writes the user and the dashboard or Look into the BigQuery job labels and query comment, so you can attribute total_slot_ms and total_bytes_billed back to content. Three reports earn their keep:
- Slot-milliseconds by dashboard, last 30 days. The top five are usually one or two executive dashboards with many tiles and no caching, and a scheduled dashboard that was created for a project that ended.
- Queries by hour of day by source (dashboard, schedule, explore, API). This shows you the peak the reservation's max has to cover and whether overnight schedules are colliding with PDT builds.
- Cache hit rate by dashboard. Looker reports whether a query was served from cache; a frequently viewed dashboard with a low hit rate is a datagroup problem, not a BigQuery problem.
When on-demand wins
On-demand charges for bytes, not time, so it rewards exactly the things good LookML already does: selecting only requested columns, filtering on partition columns, and clustering on the dimensions people group by. If your Looker queries typically scan a few hundred megabytes, on-demand at list price is cheap even at high volume. It loses when a few large queries (wide fact tables, unpruned scans, large PDT rebuilds) dominate the bill. Many teams do well with a hybrid: interactive projects on-demand, PDT and scheduled workloads in a modest Edition reservation.
PDT and aggregate strategy under slot autoscaling
Under flat-rate, the cost of a PDT rebuild was invisible; the slots were paid for anyway. Under autoscaling, every rebuild is a burst of slot-hours you can see on the invoice. Three adjustments follow:
Rebuild on change, not on a timer. Replace every persist_for with a datagroup whose sql_trigger checks a cheap high-water mark. A table that rebuilds hourly "just in case" is paying for 23 rebuilds a day that produce identical output.
Make PDTs incremental. For append-only fact tables, increment_key and increment_offset rebuild only recent partitions. A nightly full rebuild of a two-year table is the classic post-2023 cost surprise.
view: daily_order_facts {
derived_table: {
sql: SELECT DATE(created_at) AS order_date, status, COUNT(*) AS orders, SUM(amount) AS revenue
FROM `proj.ds.orders`
WHERE {% incrementcondition %} created_at {% endincrementcondition %}
GROUP BY 1, 2 ;;
datagroup_trigger: orders_daily
increment_key: "order_date"
increment_offset: 3
partition_keys: ["order_date"]
cluster_keys: ["status"]
}
}
Prefer aggregate tables to dashboard-specific PDTs. aggregate_table inside an explore lets Looker route matching queries to a rollup automatically, so one rollup serves many dashboards and the fact table is only scanned for queries that genuinely need it. Under autoscaling this flattens the peak, which is what the max slot setting is priced on. See our aggregate awareness tutorial.
Storage is a decision now too
Since 2023, datasets can bill on physical (compressed) bytes instead of logical bytes. For the large, compressible fact tables Looker explores sit on, physical billing is frequently cheaper; for datasets with heavy time-travel churn (lots of updates and deletes, long time-travel windows) it can be more expensive. Check INFORMATION_SCHEMA.TABLE_STORAGE for both numbers per dataset before switching.
A 2026 checklist for Looker teams on BigQuery
- Re-run the edition versus on-demand arithmetic on current history.
- Size baseline and max from the real concurrency curve, not from the 2023 commitment.
- Attribute slot and byte spend to dashboards, users and schedules monthly.
- Datagroups everywhere; no
persist_fortimers. - Incremental PDTs with partition and cluster keys.
- Aggregate tables for the top dashboards.
- Physical storage billing where the numbers support it.
- Delete schedules nobody reads.
If you would like this done for your instance, the spend review in our Looker health check produces exactly this checklist with your numbers filled in. Get in touch.