The situation
The warehouse bill rose every quarter, and the platform team could explain every line of it. BigQuery underneath, dbt and Airflow in the middle, a sync service feeding raw tables from the SaaS tools, Looker and Tableau on top. A few dozen scheduled jobs refreshing hundreds of tables, most of them hourly, because hourly was the default someone chose in year one and nobody had a reason to change it.
The team did what good teams do. They partitioned the big tables, clustered the ones with obvious filters, rewrote the worst models, and cut the slot time of the heaviest queries. Cost per query fell. The total did not. The refreshes still ran on the same schedule, against the same tables, whether or not anyone had opened the dashboard at the end of them.
What it looked like day to day
The table behind the CFO’s dashboard and a scratch table an analyst built in March refresh on the same hourly cadence, with the same retry policy, and show up as the same kind of line on the same bill.
A pipeline nobody can name fails three times overnight, retries three times, succeeds, and nobody opens its output for a month.
Finance asks which part of the warehouse spend is “the business” and which part is “the data team”. Nobody can split it.
The BI tool quietly pauses an idle extract. Weeks later a director opens the dashboard, sees stale numbers, and an engineer spends the morning finding out which switch to flip.
Someone proposes deleting unused tables. The meeting ends with a list of tables nobody will sign off on, because nobody can prove they are unused.
Why the usual fixes didn’t hold
Each fix worked on its own layer and stopped at its edge. Query tuning made every refresh cheaper, which is real money, but it never asked whether the refresh should run. The warehouse optimizes what you send it. It does not know who is waiting for the result, and it bills the same for a table nobody reads.
Cost dashboards found the unused tables. That was useful: the team finally had a list. But the only action on offer was deletion, and deletion needs an owner’s signature. Most of the list stayed in a spreadsheet, refreshing hourly, because retiring a table felt riskier than paying for it.
The BI tools do switch some things off. Tableau suspends an extract refresh after 32 days without views and an admin has to resume it by hand (Tableau Help). Power BI pauses scheduled refresh after two months of inactivity and someone has to re-enable it (Microsoft Learn). Both are timers, one way, with a manual restart. Neither reaches the pipelines upstream, which keep rebuilding the table the dashboard no longer reads.
The team also tried tagging critical data. A working group picked the tables that mattered. It was right for a quarter, and then the regulatory report gained a new upstream model that nobody tagged.
Same schedule, same bill
What changed with Dataring
Dataring connected to the catalog the team already opens and to a read-only account for the warehouse’s access logs. No rows, no query text.
First it mapped. Every pipeline, table, dashboard and report went onto one lineage map, from the sync service through dbt and Airflow to the BI tools, with who reads each table and how often attached.
Then it understood. From how the business actually uses the data, Dataring worked out what matters. The CFO’s dashboard and the scratch table stopped counting the same. Anything that reaches a regulator, auditor or customer is treated as critical by definition, and every table, model and pipeline upstream of it inherits that criticality at every scan, without a working group. The new upstream model that nobody tagged was critical from the scan that found it.
Critical flows upstream
Then its agents proposed, and the team accepted. Pipelines feeding critical data got priority in the scheduler and first place in line after an outage. Tables nobody read stopped refreshing hourly: as reads stopped, Dataring proposed winding the schedule down, and when reads returned it proposed restoring it, each time with the readers and dates attached. Pipelines with no readers at all were proposed for retirement, a separate action with its own sign-off. Every accepted change was logged with what was done and why.
Refresh follows demand
The decisions were the team’s. Every schedule change was accepted by a person before it was applied, and retirement always got its own review. Savings in refresh compute, rebuilds and storage were reported inside the team’s own account, in a form finance could reconcile to the invoice. Dataring works on any warehouse and is strongest on BigQuery.
What the team has now
The refresh schedule now follows demand instead of a default from year one. Hot tables refresh often. Cold tables wind down and come back when someone needs them. Nothing needs restarting by hand.
The pipelines behind executive, regulatory and customer-facing numbers are first in the queue and first to recover after an outage, and the list of what counts as critical maintains itself from lineage rather than from a meeting.
The unused-tables spreadsheet is gone. Retirement proposals arrive with the evidence attached: lineage, readers, and how long since the last read. Finance gets a savings line it can check against the bill, and the platform team gets back the argument it used to lose every quarter.
Try it on your estate
A Dataring POC runs for 30 days in your own cloud, on your catalog and your access logs. It takes about two hours of one engineer’s time to connect, on a call with us, then a 30-minute call a week.