To estimate cloud storage and compute costs before a migration, start from your measured Teradata workload history, translate each workload group into the target platform’s billing model, and model several scenarios instead of one number. Add the storage factors Teradata never billed you for, such as data retention features, duplicate data during the parallel run and non-production copies, and then calibrate the model with a pilot on the target platform.
We at DWHPro have spent more than twenty years inside Teradata systems and now lead migrations from Teradata to cloud platforms. This post is about the running cost of the target platform after go-live. The cost of the migration project itself is a separate calculation, which we cover in what a Teradata migration really costs.
Why your Teradata bill tells you little
Teradata is usually paid as fixed capacity, so an extra report or a badly written query costs nothing visible. Cloud warehouses charge for consumption: every query, every refresh and every idle minute of running compute has a price. The same workload can therefore cost very different amounts depending on how people and schedules behave after the move, as we describe in why two identical Teradata migrations produce wildly different Snowflake costs.
Start from the workload history
Teradata’s query log (DBQL) records, for each logged request, who ran it, when, how long it took and how much CPU and I/O it used. From that history we group the workload into families that behave differently on a consumption platform:
- Batch loads and transformations, with their nightly and month-end windows.
- Scheduled reporting and dashboard refreshes, which run whether or not anyone looks at them.
- Ad hoc analysis, which is spiky.
- Data science and extracts, which often read large volumes.
Insist on at least a full business cycle of history, ideally twelve months, so that quarter-end and year-end peaks are visible. If detailed logging is short today, start collecting now. Do not convert Teradata CPU seconds one-to-one into cloud units; use them to weight the workload families, and let the pilot supply the conversion factor.
How the target pricing models differ
Each platform bills compute in its own unit, and the unit shapes what your estimate must capture. Rates depend on edition, region and contract; take them from the vendors’ current pricing pages.
| Platform | Compute is billed as | What the estimate must capture |
|---|---|---|
| Snowflake | Credits. Standard warehouses consume credits by size while running. Adaptive warehouses (Enterprise Edition, select regions) size and scale themselves and bill per query. Serverless features and cloud services above a daily threshold also consume credits. | Running hours per warehouse, auto-suspend behaviour, concurrency peaks, and which serverless features you will use. |
| BigQuery | On-demand: per TiB of data processed by queries. Capacity: slots through BigQuery editions, either with the autoscaler or with one- or three-year slot commitments. | Bytes scanned per workload family for on-demand; steady and peak slot demand for capacity. The choice can differ per workload. |
| Databricks | DBUs, at rates that depend on the product and compute type. On serverless compute Databricks runs the infrastructure; on classic compute your cloud provider also bills the virtual machines in your account. | Which workloads run on serverless and which on classic compute, plus the separate cloud infrastructure bill. |
Model scenarios, not a single number
A single figure invites false confidence. We build at least three scenarios:
- Like-for-like: today’s workload, moved with minimal change.
- Optimised: the same workload after the obvious savings, such as retired reports, fewer refreshes and right-sized compute.
- Growth: new users, new data sources and the use cases the business expects once the platform is easier to use.
Each scenario lists its assumptions: refresh frequencies, active hours, concurrency, data growth. A pilot then runs representative workloads on the target and measures real consumption. Databricks recommends exactly this for estimating serverless cost, and the principle applies to every platform.
Storage: the factors Teradata never billed
Storage is usually the smaller part of the bill, but it is the part most often underestimated because of features that do not exist on Teradata:
- Compression: cloud platforms compress data in their own formats, with ratios that differ from Teradata’s. Measure it on real sample tables.
- Retention and recovery features: Snowflake bills historical data kept for Time Travel (up to 90 days on Enterprise Edition) and the seven-day Fail-safe period for permanent tables; transient tables avoid most of this. BigQuery lets you choose logical or physical storage billing, and only physical billing charges for time travel and fail-safe storage. BigQuery also charges less for tables or partitions not modified for 90 days.
- Duplicate data during migration: during the parallel run you pay for Teradata and the target at the same time, and the target often holds landing files, staging copies and the modelled data side by side.
- Retention policies: old history on Teradata will be billed every month in the cloud. Decide what to keep before loading it.
Costs outside the warehouse bill
- Non-production environments: development, test, acceptance and reconciliation runs each consume compute, and full data copies consume storage. Clones and sampled test data reduce this, but only if planned.
- Data transfer and egress: moving data across regions or clouds, extracts to on-premises systems and replication for disaster recovery are billed separately.
- Ingestion and transformation tools: managed connectors have their own pricing, and ETL logic moved into the warehouse lands on the warehouse bill.
Also price the alternative of staying: Teradata’s cloud offering added elastic compute in 2026. We discuss that decision in optimise or migrate.
What to insist on
- An estimate expressed as a range, with a written assumption register and an owner for each assumption.
- A pilot that measures real consumption before the business case is signed off.
- Budgets and spending alerts from day one on the target platform.
How DWHPro helps
We analyse your workload history, build the scenario model and validate it with a pilot, independent of any vendor. Our independent data platform assessment includes the running-cost estimate for each candidate platform.
Common questions
Can we estimate cloud costs without a pilot?
Workload history alone gives a first range that is useful for comparing platforms. Do not base a budget on it until a pilot has calibrated it.
How much query history do we need?
At least one full business cycle, ideally twelve months, so that month-end, quarter-end and year-end peaks are included. If detailed logging is short today, extend it as early as possible.
Should we buy a capacity commitment before migrating?
We advise against it. Commitment discounts exist on all three platforms, but commit only once several months of real consumption show a stable baseline.
Planning a Teradata-to-Snowflake migration?
Review the assessment, conversion, reconciliation and cutover work needed for a controlled transition.