Most companies think they have:
- a "BigQuery problem"
- a "Snowflake problem"
- a "Databricks problem"
They don't.
They have a cost system problem.
After years auditing modern data stacks (startups, scale-ups, enterprises) with bills ranging from €5,000 to €200,000 per month, one finding comes up systematically:
Bills almost never explode because of a single mistake. They explode because costs accumulate across layers that nobody analyzes as a system.
This observation led to The Data Cost Stack™.
I structured this framework after identifying the same patterns across dozens of BigQuery and Snowflake environments. Every time, the potential savings were significant (often 30 to 50% of the bill) but invisible without a systemic analysis.
What is The Data Cost Stack™?
The Data Cost Stack™ is a structured framework for analyzing, diagnosing, and reducing costs on a modern data warehouse. Whether you're optimizing BigQuery, reducing Snowflake costs, or controlling Databricks spending.
Rather than optimizing isolated queries, it breaks down cost into four systemic layers:
| Layer | Name | Focus |
|---|---|---|
| 1 | Usage | Behaviors, dashboards, ad-hoc queries |
| 2 | Flow | Pipelines, dbt, recurring jobs |
| 3 | Design | Architecture, partitioning, clustering |
| 4 | Ownership | Governance, KPIs, accountability |
Every cost problem I've encountered fits into one or more of these layers.
Not understanding this explains why so many optimization initiatives fail.
Layer 1: Usage
The visible cost
This is the most obvious layer. It includes:
- Ad-hoc queries
- BI dashboards
- Analysts scanning entire tables
- Unused dashboards that auto-refresh
- Uncontrolled experimentation
Typical example:
Dashboard refreshing every 15 min × 30 users
Monthly cost: €8,000
Actual active users: 4
The problem isn't architecture. It's behavioral.
Optimizing SQL without analyzing usage is treating a symptom.
Layer 2: Flow
The pipeline cost
This is where invisible costs hide. Flow includes:
- dbt full refreshes
- Redundant transformations
- Staging tables never deleted
- Poorly configured incremental models
- Streaming jobs without cost controls
Typical example:
dbt project: 400 models × 6 runs/day = 2,400 builds
Full refresh on 80% of models
Nobody validated if it was necessary
Cost explosions are rarely intentional. They're inherited.
I've seen a case where a dbt model cost €2,000/month because a developer set full_refresh for debugging and never removed it. The model ran like that for 14 months.
Layer 3: Design
The structural cost
This layer is architectural. It includes:
- Missing partitioning
- Missing clustering
SELECT *in production- Poor storage tier management
- No lifecycle policies
- Oversized warehouses
Typical example:
| Company | Workload | Volume | Monthly cost |
|---|---|---|---|
| A | E-commerce analytics | 500 TB | €12,000 |
| B | E-commerce analytics | 500 TB | €5,800 |
Difference: partitioning and clustering on 3 main tables.
Cost is often the direct consequence of architectural decisions made once and never revisited.
Layer 4: Ownership
The organizational cost
This is the most underestimated layer. It includes:
- No cost KPIs
- No FinOps rituals
- No budget assigned per team
- No visibility by domain
- No designated owner
Most data teams don't know how much they spend. Not because of incompetence. Because nobody designed the accountability.
Without ownership, optimization never lasts.
Quick test: Ask your Data Lead how much project X cost last month. If they can't answer in under 5 minutes, you have a Layer 4 problem.
Why this framework matters
If you only optimize Design (Layer 3) but ignore Usage (Layer 1), costs will come back.
If you improve pipelines (Layer 2) but nobody owns the cost (Layer 4), savings will disappear.
Cost is systemic. Treating it as a simple query problem is a strategic mistake.
Data FinOps should not be a reaction to a bill. It should be a discipline integrated into design.
How to apply it concretely
The power of The Data Cost Stack™ is that it structures the analysis. Rather than randomly looking for queries to optimize, you map each layer:
| Step | Layer | Key questions |
|---|---|---|
| 1 | Usage | Who consumes what? How often? For what value? |
| 2 | Flow | Which pipelines run? At what frequency? Full refresh or incremental? |
| 3 | Design | Tables partitioned? Clustered? Lifecycle policy? |
| 4 | Ownership | Who owns the cost? Are there KPIs? |
Then:
- Estimate savings per layer
- Prioritize high-impact actions
- Implement a cost-aware architecture
The result isn't a PowerPoint report. It's a structured action plan by layer, with estimated ROI for each action.
From optimization to maturity
The goal of The Data Cost Stack™ isn't just to reduce a bill.
It's to increase an organization's cost maturity. Moving from an uncontrolled modern data stack to a cost-aware architecture.
A mature data team:
- Monitors its usage
- Designs with cost in mind
- Automates lifecycle management
- Assigns an owner per domain
- Reviews costs monthly
Cost becomes integrated into design. No longer reactive. Proactive.
The long-term vision
The Data Cost Stack™ is a foundation.
The audit is step 1. Automation is step 2.
Eventually, visibility and optimization shouldn't depend on a manual audit. That's where the future of Data FinOps lies.
Conclusion
Your bill is never random. It reflects your system.
And a system can be redesigned.
If this article gave you a useful framework, share it with your data team. That's often the first step.
To go further, you can follow me on LinkedIn or subscribe to the newsletter to receive future articles.
