Cost Insights
Your warehouse bill tells you what you spent. It does not tell you which scheduled job, which pull request build, which model, or which developer spent it. Cost Insights does. It lives on the Cost Insights tab of your organization and turns the warehouse's own usage history into a picture of what your dbt work costs, broken down the way you actually think about it.
How It Works, in One Paragraph
Every query dbdeux sends to your warehouse carries a small tag naming the job, run, model, environment, and developer behind it. Cost Insights reads your warehouse's own usage history through a connection you pick, matches the tags, and adds the numbers up. Nothing is written to the warehouse, nothing is guessed from your code, and queries that did not come from dbdeux are shown honestly as Not from dbdeux so you can see your share of the total.
Setting It Up
- Open your organization and choose the Cost Insights tab
- Click Collect warehouse usage and cost and pick the warehouse connection dbdeux should read from. It only needs permission to read usage history
- Enter the price you pay per unit if your warehouse does not publish one; dbdeux tells you when a price is missing
- Wait for the first collection. The card at the top tells you exactly where things stand
The status card is never vague:
| Status | What it means |
|---|---|
| Not set up yet | No connection chosen |
| Waiting for first collection | Connected, first read in progress |
| Loading history | Backfilling past days so you have a baseline from day one |
| Up to date | Figures reflect everything the warehouse has published |
| Data is behind | The warehouse has not published recent metering yet; recent hours are estimates |
| Price missing | Usage is known, but you have not entered a rate, so no money figure yet |
| Collection paused | You switched collection off; history is kept |
| Collection failing | The connection cannot read usage history; the reason is on the card |
| Warehouse not supported | See the table below |
Three Lenses on the Same Spend
| Lens | The question it answers | Headline numbers |
|---|---|---|
| Usage | Where is the money going? | Spend from dbdeux, share of the warehouse total, breakdown by job, environment, developer, warehouse, category, or model |
| Query time | Where is the warehouse working hardest? | Warehouse execution time, average per query, failed queries, breakdown by model, run, job, or warehouse |
| Builds | What did our runs cost, and what did we avoid? | Runs with warehouse activity, models built, Saved by dbdeux State, Spent on failed runs |
Pick Last 24 hours, Last 7 days, Last 30 days, or Last 90 days; the chart adjusts its grain to match.
Categories
Spend is also grouped by what kind of work it was: Scheduled jobs, Editor runs, Slimmer CI, Semantic layer, MCP assistants, Other dbdeux, and Not from dbdeux. This is the quickest way to answer "how much of our bill is pull request builds" or "what do the AI assistants actually cost us".
The Two Numbers Finance Asks For
- Saved by dbdeux State: the warehouse usage that state-aware runs did not spend because a model was proven unchanged and skipped. It is calculated from what those models cost when they last did build, so it is a grounded figure, not a marketing estimate
- Spent on failed runs: the usage from scheduled runs that ended failed or timed out, meaning money spent before the failure. Smarter retries keep this down by rerunning only what failed
Every Warehouse in Its Own Currency
dbdeux never labels something as Snowflake credits by mistake. Each warehouse is priced the way it bills:
| Warehouse | What is measured | Priced with |
|---|---|---|
| Snowflake | Warehouse credits from the account's usage history | Your contracted rate per credit |
| BigQuery | TiB billed per query (on-demand) or slot hours (capacity and editions) | Your on-demand or capacity rate |
| Databricks | DBUs per SQL warehouse hour | The list price Databricks publishes |
| Amazon Redshift | Not supported yet | Redshift bills by node hour or workgroup, so per-query dollars would be made up. dbdeux says so rather than inventing a number |
Why Some Figures Are Estimates
Warehouses publish usage a few hours late. Rather than show a hole at the right-hand edge of every chart, dbdeux estimates the newest hours from query time and marks them as estimates. The next collection replaces them with metered values, so what you see settles on its own. Failed queries are included, because they cost money too.
Who Can See It
Every member of the organization can open Cost Insights. Choosing the connection, entering a price, and pausing or resuming collection are for organization owners and admins, and every change is written to the Audit Log.
How It Compares
| dbdeux Cost Insights | Warehouse billing console | Generic FinOps tools | |
|---|---|---|---|
| Cost per job, run, model, developer | Built in, from tags every dbdeux query already carries | Per warehouse or per user at best | Needs you to tag queries yourself and keep the tags in sync |
| What State saved you | A grounded number from the models that were skipped | Not visible | Not visible |
| What failures cost | Per run, per job | Not visible | Not visible |
| Multi-warehouse | Snowflake credits, BigQuery TiB or slots, Databricks DBUs, each in its own unit | One console per warehouse | Usually one provider |
| Honesty about gaps | Estimates marked, unsupported warehouses named, "Not from dbdeux" shown | Final figures only, days later | Varies |
| Writes to your warehouse | Never | Not applicable | Often needs agents or tables |