Findings
Cost-reduction recommendations from 16 BigQuery rules and 7 dbt rules, with a dollar estimate on each. Fix them yourself, or let the Cognis AI DBA fix them (Growth and up).
Findings are the point of a scan. Each finding is a cost pattern we can see from metadata, plus the change that removes it. All 23 rules run on every plan, including the trial.
Who makes the fix
- You, on every plan. Each finding shows the evidence and the change to make in BigQuery or dbt.
- The Cognis AI DBA, on Growth, Pro and Enterprise. Click Fix with Cognis AI DBA. It plans the change, asks for approval, applies it or opens a pull request, then checks it. See Cognis AI DBA.
A scan never changes anything. Only the AI DBA does, with its own operator key, inside your policy.
Every rule
| Finding | What it means | Type key |
|---|---|---|
| Missing partition filter | This partitioned table is queried without a filter on its partition column, so every query scans the whole table instead of just the days it needs. | FULL_TABLE_SCAN |
| Missing date filter (unpartitioned table) | This table has date columns but is not partitioned, and its queries do not filter on a date, so every query reads the whole table. Partitioning on a date column and filtering on it lets BigQuery skip the rest. | UNPARTITIONED_DATE_SCAN |
| Repeated expensive query | The same expensive query pattern runs over and over. Caching or materializing the result would avoid paying for it each time. | REPEATED_EXPENSIVE_QUERY |
| SELECT * over-fetch | Queries select every column on a wide table when only a few are actually used, so BigQuery bills for columns nobody reads. | SELECT_STAR_OVERFETCH |
| Stale / unused storage | This storage hasn't been queried in a long time but is still billed every month, at active or long-term storage rates. | STALE_LARGE_TABLE |
| Compute pricing model | Based on recent usage, a different BigQuery pricing model would cost less for this workload. | FLAT_RATE_CANDIDATE |
| CTE re-scan pattern | A common table expression reads the same base table more than once inside one query — BigQuery re-scans it each time instead of reusing the first read. | CTE_RESCAN_CANDIDATE |
| Storage billing type | This dataset is on a storage billing model that costs more than the alternative for its actual usage pattern. | STORAGE_BILLING_OPTIMIZER |
| Add clustering column | Queries filter on this column often, but the table isn't clustered on it — clustering would let BigQuery skip irrelevant blocks. | CLUSTERING_RECOMMENDATION |
| Full MERGE rewrite | A recurring MERGE, UPDATE, or DELETE is rewriting the whole target table instead of just the changed rows. | MERGE_REWRITE |
| Large table without partition or cluster | This large, actively-queried table has no partitioning or clustering, so every query scans it in full. | LARGE_UNPARTITIONED_TABLE |
| Under-utilized reservation | This capacity reservation is sized well above what the project actually consumes — a smaller baseline would still cover it. | RESERVATION_UNDERUTILIZED |
| Slot contention | This project's slot demand regularly sits at or above its reservation capacity, so queries are competing for slots. | SLOT_CONTENTION |
| Unused dbt model | This dbt model runs on every job, but nothing downstream reads its output — it may be safe to stop building it. | DBT_UNUSED_MODEL |
| dbt full-refresh churn | This model is marked incremental in dbt, but its runs are mostly full rebuilds instead of incremental merges. | DBT_FULL_REFRESH_CHURN |
| dbt materialization mismatch | This table-materialized model is rebuilt every run but is rarely read downstream — a view would likely be cheaper. | DBT_MATERIALIZATION_MISMATCH |
| Expensive dbt tests | dbt test jobs make up an outsized share of this connection's total dbt spend. | DBT_TEST_COST |
| Unbounded dbt snapshot growth | This dbt snapshot's target table has been growing steadily with no pruning policy in place. | DBT_SNAPSHOT_GROWTH |
| dbt dev / CI target spend | Non-production dbt targets (dev, CI, …) are spending a meaningful amount in the same project your production runs use. | DBT_DEV_TARGET_SPEND |
| Unused BI Engine capacity | You pay for a BI Engine reservation, but many of the queries it could speed up get no acceleration — that share of the reservation is idle memory. | BI_ENGINE_WASTE |
| Writes blocking long-term storage | This large, old table keeps getting rewritten, so its data never goes 90 days untouched and never drops to BigQuery's ~50% cheaper long-term storage rate. | LONG_TERM_STORAGE_CHURN |
| dbt model pricing model | This dbt model's own runs would cost less on the other BigQuery pricing model than the rest of its project. One line in the model sends just its queries there. | DBT_MODEL_PRICING_MODEL |
| Service account pricing model | This service account's queries would cost less on the other BigQuery pricing model than the rest of its project. A reservation assignment for just this account moves them. | SERVICE_ACCOUNT_PRICING_MODEL |
Each finding type is one rule. 16 rules are for BigQuery and 7 are for dbt.
How savings work
We store the finding identity and its evidence. When you open the finding, we join that evidence to the latest catalog and activity and estimate monthly savings. The dollar figure can move after the next scan: the table shrank, the query stopped, or prices changed.
- Prices are Google's list prices for the region the work ran in. We read them from Google's BigQuery price page every week.
- On-demand work is priced by bytes billed.
- Capacity (Editions) work is priced by slot-hours, at your reservation's edition rate times the share of its slots that were autoscale. Only autoscale slots go away when work goes away; baseline slots are paid either way. When the reservation used no autoscale, the finding says "frees ~N slot-hours" instead of dollars.
- A smaller reservation baseline saves money only for slots no slot commitment pays for. Committed slots are billed until the commitment ends.
- Pricing-model findings (on-demand or a reservation) re-price the same jobs as the other findings. They show as a separate "Or switch pricing" total, which adds up each project, dbt model and service account.
- Total potential savings on the dashboard never adds overlapping rules past the spend they share. For example, partition and cluster on the same table.
Some types are advisory and show no dollar estimate: some reservation pressure signals and dbt dev-target spend. They still tell you where to look.
The Findings page
Do this next: a line at the top names the one thing to do now, with one button. In order: fixes that wait for your approval, then finishing the Cognis AI DBA set-up, then the biggest fix, then the biggest finding your team fixes.
Savings pipeline: one savings number. Potential savings combines the fixes (two fixes on one table are not added twice). A pricing-model switch shows on its own line as "Or switch pricing: $X" and is never added in. The cards Cognis AI DBA can fix, With the Cognis AI DBA and Your team fixes split that number, and each card filters the table when you click it. Resolved (last N days) counts findings by the day they were resolved, inside your date filter (or the scan window when no date filter is on). A finding can close because you or the Cognis AI DBA fixed it, or because the waste stopped, so the resolved total is an estimate. Only fixes the Cognis AI DBA checked are proven savings.
The table
| Column | What it shows |
|---|---|
| Open for | Days since a scan first found it. Hover for the first-seen and last-seen dates. |
| Finding | The table, dataset or project in bold, then one short reason with the key number. |
| Run by | Who runs the queries behind it (workload and user or service account). They own the code to change. |
| Saves /mo | The estimated monthly saving for this one finding. "No $ estimate" when we cannot price it. |
| Next step | One control: Fix with Cognis AI DBA, Review and approve, the fix's progress, Fixed · saves $X/mo, Decide (a fix needs your call), Try again, or See how to fix. |
Open a row to see a fix card: What is wrong, The fix, You save, the evidence (who ran it, workload, Show query) and the buttons. Each group band shows how many the Cognis AI DBA can fix, and owners get Fix the biggest.
Only buttons you can use are shown. Viewers see the state, not the buttons. On a plan without the Cognis AI DBA, the row offers Fix on Growth.
Grouping
- Deduplicated groups: one row per problem, with the count of occurrences and the total saving. This is the default.
- Individual occurrences: every single finding.
Filters: severity, type (only the types you have), dataset, user, job source, dbt model, status (unresolved or resolved), and date range. With status set to resolved, the date range picks the day a finding was resolved. Use the search box for a table, dataset, user or dbt model.
Sort: by estimated savings, or by severity.
Charts: savings found and resolved over time, opened vs resolved per day, how long findings stay open, and the split by type and severity. The "By type" split adds up to Potential savings.
Resource warnings are closed by default. Click Show to read them.
Finding links open in a new tab, so you keep your place in the list.
Open a finding
Open finding page goes to the page for that finding type, searched to that table and with the row highlighted. View all N in this group keeps your filters and the fix card you picked, so the counts match the list. It shows for open findings only; with Status set to resolved, use Export CSV to get every row.
A finding type page shows:
- How to fix: 2–4 steps for this type, who fixes it (the Cognis AI DBA or your team), and one button: Fix the biggest or Review the open fix.
- The numbers: open findings, potential savings, the last scan that saw one, and the most scans any one was seen in.
- What it touches: the top findings, tables, datasets and identities. Rows open in a new tab.
- Every open finding, biggest saving first, each with the same Next step as the list. Open a row for its fix card: what is wrong, the fix, the saving, the evidence and Show query.
Resolve a finding
- Mark as resolved when you fixed it yourself.
- Findings about a table or dataset state (storage billing, missing partitioning, stale storage and similar) close by themselves when a later scan no longer sees the problem.
- A query finding counts only the last 30 days. It fades when the pattern stops running.
dbt rules
Seven rules use dbt context:
- Always, from the comments and labels dbt puts on BigQuery jobs: expensive dbt tests, dbt dev/CI target spend, and inferred materialization.
- With a
manifest.jsonupload or dbt Cloud sync: unused models, full-refresh churn, materialization mismatch, snapshot growth and the model's pricing model (one model cheaper on a reservation or on on-demand than its project), with exact materialization, owners and the model graph.
See dbt.
Workflow
- Sort by estimated savings.
- Open a group. Read the SQL or table evidence.
- Fix it yourself, assign it in your tracker, or click Fix with Cognis AI DBA.
- Wait for a later scan. The finding should close or shrink.
Export
Export CSV on the Findings page downloads what the page shows: the same filters, the fix filter and the search. It adds what_is_wrong and the_fix columns in plain text. To get findings on a schedule, use the report email (an Excel file with a Findings tab), or read them with the API (/api/v1/findings, Growth and up). See REST API and CSV exports.
Cost centers
Group BigQuery spend by department, product or business unit with ordered match rules, give each group a monthly budget, then filter the dashboard and Usage by them.
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.