Cloud Data Warehouse Renewal: Separate Storage, Compute, and Commitments Before You Reprice
Your cloud data warehouse renewal proposal has one total. Your operating environment does not.
Storage grows on one curve. Compute follows query volume, job design, runtime, and concurrency. Commitments add a third curve based on what you promised to consume, not what the business actually used. Support, data movement, serverless features, and administration can sit outside all three.
If you negotiate the total before separating those drivers, you may get a better rate on the wrong amount.
Before you renew, rebuild the decision at the workload level. Decide what to keep, resize, redesign, or compare. Then price the next term.
Stop treating the invoice as the usage model
The invoice tells you what the provider charged. It may not tell you which query, pipeline, dashboard, team, or product created the charge.
That distinction matters in data platforms. The FinOps Foundation’s current Data Cloud Platforms guidance notes that these services may meter queries, data scanned, credits, DBUs, or slots. It also calls out the difficulty of attributing pooled warehouse or cluster costs to the teams and workloads using them.
Build a renewal register that connects the commercial bill to the work performed.
| Layer | What to reconcile |
|---|---|
| Business workload | Owner, users, purpose, criticality, service window, and expected growth |
| Compute | Queries, jobs, pipelines, runtime, concurrency, capacity, serverless services, and idle time |
| Storage | Active data, retained history, replicas, snapshots, recovery copies, staging data, and growth |
| Data movement | Ingress, egress, cross-region transfer, replication, sharing, and downstream extracts |
| Commitment | Purchased units or spend, eligible usage, consumed amount, remaining balance, overage treatment, and term |
| Operations | Engineering labor, tuning, failed jobs, support, incident work, and platform administration |
Do not start with the vendor’s proposed commitment. Start with this register.
Give every workload its own economics
A data warehouse may support executive dashboards, daily finance reports, customer analytics, application features, data science, regulatory reporting, and ad hoc exploration. Those workloads should not hide inside one monthly consumption chart.
For each material workload, capture:
- Business owner, technical owner, users, and purpose
- Dependent tables, pipelines, dashboards, and models
- How often it runs and when it must finish
- Normal and peak concurrency
- Compute or bytes processed over the last 90 days
- Data stored, copied, and retained
- Failed, canceled, duplicated, or retried work
- Performance target and actual completion time
- Monthly platform cost and internal labor
A 2 a.m. finance close job and an analyst’s exploratory query may use the same platform. They do not have the same value, deadline, or capacity requirement.
If the platform cannot attribute usage cleanly, that is part of the renewal decision. Ask what metadata, query history, billing export, and allocation controls are available before buying more commitment.
Reconcile storage without assuming old data is cheap data
Storage often looks predictable, so buyers give it a quick glance and move on. That misses the operational questions behind the number.
Snowflake’s overall cost documentation separates compute, storage, and data transfer. Google likewise states in its BigQuery cost guidance that compute and storage are primary cost categories, with storage charges affected by the billing model selected for a dataset. Amazon’s Redshift Serverless billing documentation says managed storage is billed separately from compute.
The products differ, but the buying lesson is consistent: a lower compute commitment does not make retained data disappear.
Break stored data into useful groups:
- Active production data required for current operations
- Historical data with a documented business, legal, or analytical need
- Recovery data, snapshots, time-travel history, and replicas
- Staging tables, temporary outputs, failed loads, and duplicated datasets
- Data retained because nobody owns the deletion decision
Record age, access frequency, retention requirement, copy count, location, and owner. Then test a controlled archive, restore, and deletion process before changing policy.
Do not delete data because a spreadsheet labels it cold. Legal hold, recovery, audit, and application dependencies still apply.
Price compute from workload behavior
Compute is not one thing across the major platforms.
Snowflake documents credit use across virtual warehouses, serverless compute, and cloud services. Its compute cost guidance says virtual warehouse credits depend on the number of warehouses, their size, and how long they run. BigQuery offers on-demand query processing and capacity-based pricing, according to Google’s cost guidance. Redshift Serverless measures active compute in RPUs and bills storage separately, according to AWS.
A proposal that says “compute” may therefore include very different meters and controls.
Reconcile the last 90 days by workload. Look for:
- Warehouses or clusters running with little useful work
- Jobs that scan or process far more data than their output requires
- Peak concurrency caused by poor scheduling rather than business demand
- Repeated failures and automatic retries
- Development and test activity sharing production capacity
- Serverless features or background services outside the expected meter
- Capacity added to solve a performance issue that was never diagnosed
Smaller compute does not always save money. A smaller resource that runs much longer may cost more and miss the service window. Test representative workloads at different settings and compare consumption, runtime, failures, and user impact.
This is why list-price comparisons are weak. The useful unit is cost per completed business workload at an acceptable service level.
Size the commitment after the cleanup
Commitments can reduce unit rates when demand is steady. They can also turn an optimistic forecast into prepaid waste.
Google’s BigQuery reservations documentation says capacity commitments are optional, can support steady workloads, and cannot be canceled monthly during their term. AWS documents that Redshift Serverless can combine reservations with on-demand resources. Those are product examples, not a recommendation for either model.
Your agreement controls your actual rights and obligations. Read it.
Build a commitment table with:
| Question | Evidence required |
|---|---|
| What did we buy? | Unit definition, quantity or spend, rate, edition, region, start date, and end date |
| What consumed it? | Eligible services, workload usage, excluded charges, and allocation records |
| How much was unused? | Monthly burn, remaining balance, expiration, and any carryover language |
| What exceeded it? | Overage units, rate, timing, and invoice treatment |
| What changes next term? | New workloads, retired workloads, architecture changes, growth assumptions, and price changes |
| What can we change? | Ramp schedule, reallocation, conversion, renewal notice, and termination terms |
Use cleaned, representative demand to establish a defensible floor. Keep uncertain growth outside the committed floor until the workload has real usage and an accountable owner.
A forecast for a new AI, analytics, or customer-data workload is not consumed capacity. Price that uncertainty honestly.
Put performance beside cost
A cost reduction that breaks month-end reporting is not optimization. A performance upgrade that cuts two seconds from an unused dashboard may not deserve a bigger commitment.
For each critical workload, put these measures on the same line:
- Completion time and required service window
- Queue time and concurrency during normal and peak periods
- Failure, cancellation, and retry rate
- Data freshness at the point of use
- Compute consumed and storage assigned
- Business owner and consequence of failure
Now you can see whether extra capacity fixed a real business problem, masked inefficient work, or sat idle.
Require a controlled benchmark before accepting a major resize or platform change. Use representative data, expected concurrency, actual logic, and a defined success threshold. A vendor demo query does not establish your production economics.
Price the work around the platform
The platform bill is only part of the renewal.
Include the labor required to run ingestion, transformations, orchestration, access controls, data quality, observability, tuning, backup, recovery, and user support. Include adjacent tools if the warehouse depends on them. Include cloud transfer charges and duplicate storage created by the surrounding architecture.
Then inspect migration exposure even if you plan to stay.
Can your team export data in a usable format? Can it recreate schemas, roles, policies, pipelines, tests, dashboards, and schedules? Which features or SQL patterns do not move cleanly? How long would both environments need to run?
You do not need to threaten a platform replacement at every renewal. You do need enough evidence to know whether “we cannot move” is true, temporary, or just untested.
The cloud commitment renewal checklist covers broader commitment risk. Our cloud cost optimization guide can help if the warehouse review exposes ownership and allocation problems across the rest of the cloud estate.
Make four decisions, not one
Place each workload and cost component into one of four treatments.
Keep it when the workload has an owner, delivers required value, meets its service level, and consumes resources within an understood range.
Resize it when the workload is valid but storage, compute, schedule, concurrency, or commitment no longer matches actual demand.
Redesign it when bad queries, duplicated pipelines, excessive retention, weak scheduling, or surrounding tool choices are driving avoidable cost or poor performance.
Compare another commercial model, service, or platform when the current option cannot meet required economics, controls, portability, support, or performance after reasonable correction.
Apply the decision workload by workload. A company can keep the platform, resize its steady capacity, redesign two expensive pipelines, and compare an alternative for one new use case. Renewal does not need to force the entire environment into one answer.
Put the evidence into the renewal record
Before approval, attach the workload register, 90-day usage baseline, storage inventory, performance results, commitment reconciliation, billing export, operational labor estimate, and open remediation list.
Make the proposal state:
- The exact pricing units and eligible services
- Rates for committed, on-demand, and overage consumption
- Storage, transfer, support, and serverless charges outside the main commitment
- Ramp, reallocation, expiration, and renewal treatment
- Usage reporting and export access
- Performance and support responsibilities
- Data export, deletion, transition, and assistance obligations
- Owners and due dates for any promised optimization work
Your data warehouse renewal is not a discount exercise. It is a workload, architecture, and commitment decision with a contract wrapped around it.
Separate the parts before you reprice the whole.
If your Snowflake, BigQuery, Redshift, Databricks, or other data platform agreement is approaching renewal, schedule a technology vendor negotiation review. Catch Advisors can help you reconcile workloads, usage, commitments, performance, contract terms, and migration exposure before you renew, resize, or compare options.