Your warehouse sees what ran. dbt sees what was built. Your catalog sees what is stored. None can say why something broke or cost more. NaviLake traces it across layers, proposes the exact change, and checks afterwards that it worked.
Current metadata.json moved on — newer than the BigQuery pointer
External table still pins an older metadata file
Readers get a stale snapshot. No error. No alert.
Impact
Stale snapshot, no error
Table
1 external table
First fix
Re-point at current metadata.json
Illustrative — Iceberg catalog vs BigQuery external pointer. Not a live finding and not a dollar claim.
We sit in your existing stack. Nothing to move.
A reader account. Nothing installed in your jobs.
Metadata and job history only.
Your catalog stays in your account.
The loop
We propose. You apply through your normal process. We check afterwards that it worked.
Architecture
A single connector shows you one layer. Two connectors unlock cross-system causality. BigQuery, dbt, and Iceberg REST are in the product today — and each connector you add compounds what NaviLake can trace back to its origin.
Live todayBigQuery · dbt · Iceberg RESTSpark next
Compounds with every connector added
Root Cause
Iceberg catalog current metadata.json moved on. BigQuery still pins an older file.
What we find
Every finding says what happened, what the evidence is, and what to change. Dollars only when we can attribute them.
Catalog current metadata.json moved on. BigQuery still pins an older file.
Traced across. Iceberg catalog location → BigQuery external table uris
Proposed change. Re-point the table at the current metadata file.
fct_events is partitioned by day of event_ts. Compiled SQL never filters it.
Traced across. Iceberg partition spec → dbt compiled SQL
Proposed change. Add a predicate on event_ts, or evolve the spec to match the filters.
Oldest snapshot is older than the retention in force, with nothing pinning it.
Traced across. Iceberg snapshots → declared snapshot retention
Proposed change. Expire snapshots on your compute. Recommend-only.
Writes stopped, then reads stopped. No dbt model points at it.
Traced across. BigQuery last read → dbt model mapping
Proposed change. Confirm no consumers, then drop. Your team applies it.
A model stopped writing. Status stayed green. Dashboards served frozen numbers.
Traced across. dbt write cadence → BigQuery table freshness
Proposed change. Restore the write, or stop serving the stale table.
A recurring query keeps erroring. Failed on-demand jobs never appear on the bill.
Traced across. BigQuery job history
Proposed change. Fix the query, or stop the schedule.
An Iceberg catalog knows the current snapshot. BigQuery knows which file it was pointed at. Neither notices when those disagree — because that fact lives in the relationship between catalog and warehouse.
The problem
The engineer becomes the integration layer, stitching root causes together by hand.
Across layers
Iceberg knows the partition spec. dbt knows the compiled SQL. Neither notices the model never filters the partition column, so pruning cannot apply.
NaviLake correlates across the boundaries to catch what slips between the cracks.
Illustrative example — Iceberg + dbt
Partitioned by day of event_ts — compiled SQL never filters it. Illustrative example.
Iceberg layer
event_tsTransformation layer
event_ts, so pruning cannot applyRoot Cause
event_ts. The mapped dbt model's compiled SQL never filters that column, so the partition cannot prune those reads.Outcomes
Every change is proposed with its evidence. Your team reviews and applies it through your normal process.
Optional Iceberg property writes — for example snapshot retention — are grant-gated, reversible, and default off. Compact, expire, and orphan stay recommend-only. Table-format stay-or-look-closer advice is on the roadmap, labelled as a heuristic.
Daily dbt refresh triggers full-table scans — partition pruning never kicks in. Illustrative example.
Transformation layer
order_events does a full refresh daily with no partition filterWarehouse layer
event_date — but the model never filters on itQuery pattern
Root Cause
event_date partition filter. BigQuery can't prune partitions, so every run scans the full history.Verification
proposed
The change is recommended. Nothing has been applied.
delivered
Your team applied it. We are re-measuring.
verified
The measured metric moved in the intended direction.
no change
The change landed. The metric did not move.
regressed
The metric moved the wrong way.
For leadership
Surfaces tables with no reads observed, orphaned pipelines, and storage patterns as soon as BigQuery, dbt, or Iceberg REST is connected.
Time saved per incident — root cause surfaced instantly instead of manually stitched together across tools.
Time from a connected BigQuery project to a first finding — after jobs are in, not a public self-serve timer.
Every finding that carries a dollar has a confidence score and the evidence behind it. Findings without a defensible number show the pattern and omit the $. You and your team look at the same record.
This isn't a tool that adds to your stack of dashboards nobody checks. It's the thing that explains why the other dashboards say what they say.
NaviLake never runs DDL or DML in your warehouse. Every change is proposed with its evidence. Your team reviews and applies it through your normal process. Read-only on BigQuery: metadata and jobs, never table rows.
Status
Correlated together — findings from one layer enrich the other.
Each new connector compounds what every connector before it can see.
Security
We never read table rows. Roles, writes, and what we have proven are listed once below.
Read-only. Metadata and jobs.
That role reads table rows.
dataViewerWe read schema, statistics, and job history — never your actual data files, and BigQuery access is read-only.
Every change is proposed with its evidence. Your team reviews and applies it through your normal process. NaviLake never executes against BigQuery. Compact / expire / orphan stay recommend-only; you run them on your compute.
Each recommendation keeps the evidence that produced it. The one catalog write we offer is an Iceberg property change that is grant-gated and default off: it needs an explicit org grant, an approved change stores the inverse, and it can be reverted. Warehouse rollback stays your team's change process.
Iceberg REST is in-product, proven on our synthetic tenant and local Polaris, not claimed on every customer catalog.
"Every data team we've ever been part of had the same failure mode: five excellent tools, each confident about its own layer, none of them agreeing on the full picture. We didn't want to build another excellent single-layer tool. We wanted to build the layer that sits above all of them — one that gets more valuable every time you connect something new to it, not less.
BigQuery and dbt are where we started because that's where the pain is sharpest today. Iceberg REST is in the product now. Spark is next, and it won't be where we stop."
Access
BigQuery + dbt is live today. Iceberg REST is in-product. We will tell you what a paid seat looks like after you have seen findings on your own jobs — not before. There is no 50-table free SKU, no Growth/Scale grid, and no Iceberg health plan on a price card we do not sell.
Email hello@navilake.comNo migration. No agent required. We never read table rows. We do not host your catalog.