Data Foundations
SaaSUse case, not a client storyStop paying for a warehouse nobody can query fast.
The warehouse bill goes up every quarter. Dashboards still take a minute to load, and nobody can say which team or query is driving the cost. We find where the money goes, fix it, and keep it fixed.
Where the bill goesSchematic
Dashboards refreshing every few minutes
Full rebuilds of tables that barely change
Compute left running overnight
Queries that answer a real question
A common pattern, not a measurementPay for answers
3.4×Target return in 12 months
Week 1Fixed-fee audit
6 weeksTo the first live result
3Senior people on the work
TypeUse case: what we build, not a client story
ForSaaS founders, CTOs and data leads whose warehouse bill grows faster than its use
EngagementWeek 1 audit, then build in about six weeks, fixed scope, fixed fee
Runs onThe cloud warehouse you already have, or Antvia in your own cloud on open formats
The problem
A growing bill, and slow answers anyway.
The warehouse was set up quickly, and it worked. Then more dashboards arrived, more tables, more people. Nobody owns the cost, so nobody sees that most of it pays for work no one reads.
What was broken
- Dashboards refresh every few minutes, even when nobody opens them.
- Large tables are rebuilt in full every night when only a few rows changed.
- Tables are stored in a way that does not match how they are read, so every query scans far more than it needs.
- Compute is sized for the busiest hour and left running the rest of the day.
- The bill arrives as one number, with no split by team, dashboard or query.
You might be here if
- Your warehouse bill has grown faster than your customer count.
- Your team waits for dashboards, or exports to a spreadsheet to work faster.
- Nobody can tell you which query costs the most.
- Someone has suggested moving to a new platform to fix it.
Why it mattered. A slow, expensive warehouse teaches people to stop asking questions. The cost is not only the bill. It is the decisions made without data because getting the data felt too slow.
The approach
Measure first. Then fix the cheapest things.
In Week 1 we read the query history and the bill, and split the cost by query, dashboard and team. That list usually shows a handful of jobs doing most of the damage. We fix those first, in the warehouse you already have, and only then talk about anything bigger.
Today
One big monthly bill
Slow dashboards
Full nightly rebuilds
woodfrog method
Split the costBy query, dashboard and team
Fix the worst jobsModels, storage layout, refresh schedules
Right-size and budgetCompute per job, a limit per team
What changes
A bill you can explain
Dashboards that load quickly
Pay for answers, not idle work
Deliberately not doneMoving everything to a new platform before the cheap fixes are made
The solution
A warehouse you can explain, and afford.
What we build
- A cost view that splits the bill by query, dashboard and team, refreshed daily.
- Incremental models that process only new and changed rows, in place of full nightly rebuilds.
- Tables partitioned and ordered the way your team actually reads them, so queries scan less.
- Refresh schedules tied to how often each dashboard is opened, and summary tables for the heavy ones.
- Compute sized per job, with automatic suspend when idle.
- A budget per team with an alert before it is crossed, and a short guide so your team can keep it that way.
We work in the warehouse you already have. If a move makes sense later, Antvia runs a bronze, silver and gold lakehouse plus BI in your own cloud on open formats, so your data is never locked to one engine.
How it would runBuild runs from Week 2 to Week 6. Operate is open-ended and drawn at one week only to fit.
Wk 1Wk 2Wk 3Wk 4Wk 5Wk 6Wk 7
Audit
Cost by query
Worst jobs
Models, refreshes
Storage and compute
Layout, sizing
Budgets
Per team, alerts
Operate
Ongoing
Wk 1Wk 2Wk 3Wk 4Wk 5Wk 6Wk 7
Audit
Cost by query
Worst jobs
Models, refreshes
Storage and compute
Layout, sizing
Budgets
Per team, alerts
Operate
Ongoing
The impact
What we would measure.
Four levers, in this orderCheap fixes first. A move to a new platform is the last lever, not the first.
Schematic, no values1See itCost and run time per query, per dashboard, per team
2Model itBuild only what changed, store tables the way they are read
3Size itRight compute for each job, switched off when idle
4Budget itA limit per team, with an alert before it is crossed
Audit, then build: about six weeksOperate: return tracked every month
Measured on your own numbers, the same way as the baseline. The promise is at least 3× within 12 months of delivery.
What we would measure on a real engagementWhat we would measure
Monthly warehouse costAgainst the Week 1 baseline, split by team
Dashboard load timeFor the dashboards people open most
Share of cost with an ownerEvery query and dashboard tagged to a team
Data processed per runRows and bytes scanned by the heaviest jobs
Return on the workTarget: at least 3.4× within 12 months, measured on your own numbers
Find out where your warehouse money goes.A short call, or record a message. A person replies within one business day.
