Data Warehouse migration paths

Cloud data-warehouse spend is usage-based and notoriously hard to forecast, credits, per-TB-scanned billing, and separately metered compute/storage/egress. Snowflake bills compute and storage separately and adds egress and feature charges on top; BigQuery’s per-TB-scanned model punishes wide, unoptimized queries; Redshift bills for provisioned capacity plus egress and concurrency; and legacy Teradata carries premium per-TB licensing and hardware. Open engines and lakehouses, ClickHouse, Trino/Starburst, DuckDB, Druid, can cut cost dramatically for the right workloads, especially analytical and high-volume ones. The catch is that every one of these moves is a re-platform with real SQL and modeling work, not a connection-string swap, so scope it honestly before committing.

Match the engine to your query shape

• ClickHouse, blazing columnar OLAP; great for real-time analytics and high ingest. It models data with an ORDER BY primary key and PARTITION BY on a MergeTree engine rather than sort/dist/cluster keys, and it is excellent for append-heavy, aggregation-first workloads. It is not a drop-in for every warehouse job: heavy multi-table transactional updates and complex slowly-changing-dimension patterns need rethinking.
• Trino, query engine over a lakehouse (Iceberg/Delta/Parquet on object storage); decouples compute from storage, and a strong option when your workload is JOIN-heavy star-schema BI with unpredictable concurrency.
• DuckDB, in-process analytics, excellent for embedded and mid-size workloads where a full cluster is overkill.

Match the engine to your query shape rather than picking one reflexively. If most of your spend comes from high-volume scans and aggregations, ClickHouse usually wins; if it comes from broad ad-hoc BI wired deep into a cloud ecosystem, weigh Trino or staying put for those workloads.

Use open formats as the bridge

The clean migration path is export to Parquet/Iceberg on object storage, then load into the target. This avoids vendor-specific dump formats and gives you a reusable lakehouse layer. The exact export tool depends on the source: Snowflake unloads with COPY INTO a stage, BigQuery with EXPORT DATA to GCS, Redshift with UNLOAD to S3, and Teradata with TPT (Teradata Parallel Transporter). Targets like ClickHouse then read those files straight from object storage via table functions such as s3() and gcs(), with no intermediate loader. Inventory schemas, datasets, ETL/ELT jobs, BI connections, and SQL-dialect specifics first.

SQL & ETL conversion

Each engine has dialect differences (functions, types, window syntax, semi-structured handling). Snowflake VARIANT and FLATTEN, BigQuery STRUCT and APPROX_COUNT_DISTINCT, Redshift’s Postgres-flavoured window and JSON functions, and Teradata QUALIFY and BTEQ scripts all need converting, not copying. On the modeling side, sort keys, distribution keys, and clustering columns from the source do not carry over: in ClickHouse they become an ORDER BY primary key plus coarse PARTITION BY, and that layout choice is the single biggest lever on performance. Convert and test key queries on a sample dataset before full load, and re-point ETL/ELT pipelines and BI tools (Tableau/Power BI/Looker) to the new engine.

Reconcile both systems before you switch consumers

Export full datasets, load into the target, and run both systems in parallel, reconciling row counts and aggregate results plus query-correctness and performance benchmarks. Switch BI/consumers to the target only after sign-off; keep the source authoritative until reconciled.

Proving the saving under real concurrency

Bills scale with TB managed and query concurrency. Self-hosted/open engines shift cost to compute + storage + engineering, usually far lower for steady analytical load, but you now own capacity planning, patching, and scaling that the cloud warehouse handled for you. Prove the saving during a parallel run rather than estimating it up front: put the retired usage or licensing spend against the new infrastructure (or managed-service) cost for the same migrated queries, and treat the delta as illustrative until the numbers and latency hold under real concurrency. Model against your real data volume and concurrency.

Use the TCO calculator to model a per-TB comparison.