Cognis AI
Cognis AI DBA docs
The AI DBA fixes findings for you: safe BigQuery changes and GitHub pull requests, each one approved, logged, checked and reversible. On Growth, Pro and Enterprise.
The Cognis AI DBA turns a finding into a real fix. It plans the change, asks for approval, makes the change, then checks that it worked. Every step is logged.
There are two kinds of fixes:
- BigQuery changes: for example, add clustering columns or shorten a time-travel window. These use a separate operator key that you create with only the write permissions you choose.
- Pull requests: for dbt models and query code in your GitHub repo. The AI DBA opens the pull request. A person always merges it. SlashPeak never merges.
A scan never changes anything
The scanner key stays read-only on every plan. Only the AI DBA changes things, only with its own operator key or GitHub App, and only inside the rules you set.
Plans
| Growth | Pro | Enterprise | |
|---|---|---|---|
| AI-written fixes | Use your AI usage (2.5x) | Use your AI usage (5x) | Custom |
| Fix pull requests open at once | 3 | 10 | 20 |
| GitHub repos connected | 2 | 10 | 25 |
| dbt Cloud CI runs per pull request | 1 + 1 re-run | 1 + 3 re-runs | 1 + 4 re-runs |
| AI DBA action log | Each event kept 12 months | Same | Same |
The trial and Starter do not have the AI DBA. See Plan limits.
How a fix works
Pick a finding. On Findings, click Fix with Cognis AI DBA on a finding it can fix.
Plan. The AI DBA reads the live state of the table, dataset or model. It writes the exact change: the API call, the DDL, or the file diff. Nothing runs yet.
Policy check. Your policy decides: run by itself, wait for an owner, or block. The action page shows the decision and why.
Approve. If approval is needed, an owner reads the plan and clicks Approve or Reject. The approval is tied to that exact plan. If the plan changes, it needs a new approval.
Apply. The AI DBA makes the change, or opens the pull request. If the resource changed since the plan, it plans again first.
Verify. For the verification window (24 hours by default), it checks that the change is still in place. For a pull request, it waits for the merge and then for the first production run that uses it.
A plan older than 24 hours is made again before it runs. A plan nobody approves in time expires.
What it can fix
| Action | What it does | Who starts it | Undo |
|---|---|---|---|
| Add clustering columns | Adds the recommended columns to the table's clustering, so queries that filter on them read less data. Only a setting changes: no data is rewritten and it costs nothing. Undo restores the old columns. | Can run by itself, if your policy allows | Yes |
| Shorten time-travel window | Shortens how far back BigQuery keeps old versions of the dataset's tables, to 48 hours. It saves money only on datasets billed by physical storage. History older than the new window cannot be restored. | Can run by itself, if your policy allows | Yes |
| Switch storage billing model | Switches how the dataset's storage is billed, between logical and physical bytes. It always needs an owner. Google blocks another switch for 14 days, so undo is only possible after that. | Always needs an owner | No |
| dbt: set cluster_by | Opens a pull request that sets cluster_by in the dbt model's config(). dbt rebuilds the table, so a direct BigQuery change would be undone. A human merges it; we never do. | Can open its pull request by itself; a person merges | Yes |
| dbt: set partition_by | Opens a pull request that sets partition_by in the dbt model's config(). The table needs one full rebuild (dbt run --full-refresh) to pick it up. | Can open its pull request by itself; a person merges | Yes |
| dbt: change materialization | Opens a pull request that builds the dbt model as a view instead of a table. The build cost goes away; each read runs the model's SQL. | Can open its pull request by itself; a person merges | Yes |
| dbt: disable model | Opens a pull request that sets enabled=false on a dbt model nothing reads. The code stays in the repo; undo is a revert. The old table is not dropped. | Can open its pull request by itself; a person merges | Yes |
| dbt: add incremental predicates | Opens a pull request that adds incremental_predicates, so each MERGE reads only recent target partitions. Late rows older than the window are not matched. | Can open its pull request by itself; a person merges | Yes |
| Rebuild table with partitions | Rebuilds the table with partitions: a partitioned copy, a row-count check, then a swap. The original is kept as a backup. It reads the whole table once. Undo swaps back. | Always needs an owner | Yes |
| Drop the rebuild backup table | Deletes the backup table a verified rebuild left behind. It needs its own approval, after the retention window. It cannot be undone. | Always needs an owner | No |
| Add a partition filter (AI PR) | Claude reads the query's source file and opens a pull request that adds a filter on the table's partition column, so BigQuery reads only the partitions it needs. A wrong date range changes results: review it. | Can open its pull request by itself; a person merges | Yes |
| Rewrite MERGE predicate (AI PR) | Claude edits the MERGE statement so its ON / WHERE clause names the target's partition column, and BigQuery skips old target partitions. The pull request states the look-back window; confirm it covers late rows. | Can open its pull request by itself; a person merges | Yes |
| Replace SELECT * (AI PR) | Claude replaces SELECT * with the columns the code and its downstream models use. On-demand billing charges per column read. The output columns change: review downstream users. | Can open its pull request by itself; a person merges | Yes |
| Materialize a CTE (AI PR) | Claude merges the CTEs that read the same base table into one upstream CTE, so the table is scanned once. The result must not change; at most two new CTEs, no temporary tables. | Can open its pull request by itself; a person merges | Yes |
| Limit dbt tests (AI PR) | Claude adds `config: where:` limits to the costliest dbt tests in schema.yml, so they test recent data only. Tests are narrowed, never removed. | Can open its pull request by itself; a person merges | Yes |
| Fix incremental model (AI PR) | Claude reads the incremental model and fixes why it rebuilds the whole table (for example the is_incremental() logic or full_refresh). If the cause is the scheduler command, it gives up with advice instead. | Can open its pull request by itself; a person merges | Yes |
| Create materialized view | Creates a materialized view that Claude designed for a repeated query; BigQuery then uses it for that query by itself. Our code writes the DDL. Undo drops the view. | Always needs an owner | Yes |
| Resize reservation | Lowers the reservation's baseline slots, never below what your queries use at their busiest and by at most half per step. Autoscale is not touched. Undo restores the old baseline. | Always needs an owner | Yes |
| Shrink BI Engine reservation | Shrinks the BI Engine reservation by the share of queries it did not speed up, by at most half per step and never below 1 GiB. It does nothing when most misses are because the reservation is too small. It rolls back by itself if fewer queries get accelerated afterwards, and waits 14 days before the next shrink. Undo restores the old size. | Always needs an owner | Yes |
| Write only new partitions (AI PR) | Claude changes the code that writes the table so each run writes only new partitions (an append, a partition overwrite, or a MERGE limited to recent partitions). Old data then ages into the long-term rate, about half price. A wrong window drops or doubles rows: review it. | Can open its pull request by itself; a person merges | Yes |
| Quarantine stale table (7-day expiry) | Sets the unused table to delete itself in 7 days. It keeps working until then, and any read or write we see cancels the expiry. After 7 days BigQuery deletes it and it cannot be restored. | Always needs an owner | No |
| Move project to the cheaper pricing model | Moves the project to the cheaper pricing model: onto a reservation, or off it to on-demand. New queries follow within about 5 minutes. With a time-of-day schedule you approve once and it moves the project before each block until you undo it. It rolls back by itself if the project's p95 query time doubles. Undo restores the old assignment. | Always needs an owner | Yes |
| dbt: run model on the cheaper pricing model | Opens a pull request that sets the dbt model's sql_header to SET @@reservation, so only this model's queries run on the reservation (or on on-demand with 'none'). The project's assignment does not change. Undo is a revert. | Can open its pull request by itself; a person merges | Yes |
"Always needs an owner" means no policy setting can let it run by itself. "Can run by itself" still needs your policy to allow it.
Which finding gets which fix
| Finding | Fix on a plain BigQuery table | Fix on a dbt model | Fix in other query code |
|---|---|---|---|
| Add clustering column | Add clustering columns | dbt: set cluster_by | — |
| Storage billing type | Shorten time-travel window, or switch storage billing model | — | — |
| Missing date filter / large table without partition | Rebuild table with partitions | dbt: set partition_by | — |
| Missing partition filter | — | Add a partition filter (AI PR) | Add a partition filter (AI PR) |
| SELECT * over-fetch | — | Replace SELECT * (AI PR) | Replace SELECT * (AI PR) |
| Repeated expensive query | Create materialized view (needs an owner) | — | — |
| Table read twice in one query (CTE rescan) | — | Materialize a CTE (AI PR) | Materialize a CTE (AI PR) |
| Expensive dbt tests | — | Limit dbt tests (AI PR) | — |
| dbt full-refresh churn | — | Fix incremental model (AI PR) | — |
| Full MERGE rewrite | — | dbt: add incremental predicates | Rewrite MERGE predicate (AI PR) |
| dbt materialization mismatch | — | dbt: change materialization | — |
| Unused dbt model | — | dbt: disable model | — |
| Under-utilized reservation | Resize reservation | — | — |
| BI Engine waste | Shrink BI Engine reservation (not when most misses are because the reservation is too small) | — | — |
| Long-term storage churn | — | Write only new partitions (AI PR) | Write only new partitions (AI PR, partitioned tables only) |
| Compute pricing model | Move project to the cheaper pricing model (one move, or a daily schedule) | — | — |
| dbt model pricing model | — | dbt: run model on the cheaper pricing model | — |
| Service account pricing model | Advice only while Google's principal assignments are Preview | — | — |
| Stale / unused storage | Quarantine stale table | — | — |
If dbt builds a table, the AI DBA uses the dbt fix. A direct BigQuery change would be undone by the next dbt run.
Findings with no fix in this table show a draft of advice only.
The AI DBA page
Open Cognis → Cognis AI DBA (/cognis/dba).
- Header button: always the most urgent step. Review 2 fixes when fixes wait for you, Finish set-up when something is missing, otherwise Find fixes (opens the findings Cognis AI DBA can fix, in a new tab).
- Set-up checklist: shown until you are done. Turn on Cognis AI DBA, add an operator key, connect GitHub (only if pull request fixes are on) and allow AI-written fixes (only if AI fixes are on). Each row has a button to the right settings tab.
- Needs you: fixes waiting for an owner. That means fixes waiting for approval, fixes someone changed after the fix (Regressed), and pull requests that were merged but never seen running. Each row says why it needs you, how long you have to approve it, and has a Review button. The whole row opens the fix.
- Overview: the mode (On, Off, Paused or Draft only), open fixes, and savings. Every number has an info tip. Verified savings is our estimate for fixes that were checked, not a figure from your bill. The totals count every fix, not only the rows the page lists.
- Queue: every other fix, grouped as In flight, Verifying, Pull requests, Drafts, Done, and Stopped or failed. Stopped rows show one plain next step, such as Change policy or Add key. The Finding column opens the finding on its row, in a new tab.
Your AI usage and pull request counts are on Cognis → Activity, in the Plan usage card.
Click an action to see:
- The decision card: the change in one sentence, what it saves, the risk, why it needs you, what happens after you approve, and how long the plan is valid. Approve and Reject sit in this card. Viewers see the same facts and "Only an owner can approve this fix". If the plan expired, the card shows Plan again instead of Approve. If Cognis AI DBA is paused, it says an approved fix waits until an owner resumes it.
- What changes: the setting before and after, for storage billing, time travel, clustering, quarantine, reservation resizes and BI Engine shrinks.
- Plan: the pull request diff, the DDL steps or the pricing move, when the fix has one.
- Timeline: what happened, in plain words ("Planned the change", "Waiting for an owner to approve", "Verified: the change is still in place"). The raw event code is under Details.
- Technical details (closed): the request, rollback and before-state JSON, plan hash, etag, plan revisions, attempts and AI traces.
- Open finding (new tab, on the right row) and View in audit log (Activity filtered to this fix).
- Buttons: Approve, Reject, Plan again, Cancel, Dismiss, Roll back, Re-run CI. A button only shows when you can use it: not for viewers, not after a plan expired, not for a fix that is already final.
Action status
| Status | Meaning |
|---|---|
| Draft | Planned. The policy is in draft mode, so it never runs |
| Needs approval | Waiting for an owner. The plan is valid for 24 hours, then it expires |
| Approved | Runs on the next worker pass |
| Applying | Making the change |
| Applied → Verifying → Verified | Done, and still in place after the verification window. A time-of-day pricing schedule stays in Verifying while it runs: the AI DBA moves the project 5 minutes before each block until you roll it back |
| Opening PR → PR open → PR merged | A pull request is on its way |
| Merged, not seen running | Merged, but no production run used it within 14 days. It shows under Needs you: check your deploy, Roll back (a revert pull request), or Dismiss (keep the change and clear it from Needs you) |
| PR closed | Closed without a merge. The same fix is not suggested again for 14 days |
| Regressed | Someone changed the resource after the fix. The AI DBA flags it but never undoes a human change. It shows under Needs you: Roll back or Dismiss |
| Rolling back → Rolled back | Undone at an owner's request |
| Denied by policy | Your policy blocked it |
| Rejected, Cancelled, Expired, Superseded | Stopped by a person, by time, or by a newer plan |
| Failed, Invalid, Not fixable | Could not be done. The page says why |
Undo (roll back)
Most actions can be undone. Click Roll back on the action page.
- A BigQuery change is set back to the old value. If someone changed the value since, the roll back is refused so it does not overwrite their work.
- A pull request fix is undone with a revert pull request. The roll back finishes when someone merges the revert.
- Some actions cannot be undone. The table above marks them. They always need an owner's approval:
- Switch storage billing model: Google blocks another switch for 14 days.
- Quarantine stale table: after 7 days BigQuery deletes the table. Any read or write that the scans see before then cancels the expiry.
- Drop the rebuild backup: deletes the
_dpc_oldcopy left by a partition rebuild. It is a second, separate approval, after 7 days.
Pause
An owner can click Pause Cognis AI DBA at any time. No step runs until an owner resumes. Pending approvals stay where they are. If you approve a fix while it is paused, the approval is kept and the fix runs after an owner resumes.
Notifications
AI DBA events go to your Slack channel and your webhook, if they are set up in Settings → Notifications. Webhook events are dba.action.awaiting_approval, dba.action.pr_opened, dba.action.applied, dba.action.verified, dba.action.regressed, dba.action.rolled_back, dba.action.failed and dba.paused. See Alerts and notifications.
Audit log
Every step is written to an append-only log: who or what did it, the BigQuery or GitHub call, and the result. Secrets are removed first. See it in Cognis → Activity and on Audit logs. Each event has a plain title, a link to its fix and finding, and the raw code under Details. Open View in audit log on a fix to see only its events.