Performance tuning & optimization
Workload scope
Performance tuning and optimization covers the target-platform changes needed to keep migrated workloads predictable for runtime, cost, concurrency, and service-level expectations.
Use this hub to find the source-to-target pages that already include workload-specific conversion risks, supported patterns, validation gates, examples, and cutover criteria. The hub is intentionally tied to the migrated child-page corpus so missing child content remains visible during parity review.
Related migration paths
- Databricks to BigQuery - Tune BigQuery after Databricks migration with pruning-aware rewrites, partitioning/clustering, slot strategy, and regression gates to keep spend predictable.
- Databricks to Snowflake - Tune Snowflake after Databricks migration: bounded MERGE patterns, clustering strategy, warehouse sizing, and regression gates for stable performance and spend.
- Hadoop legacy cluster to BigQuery - Tune BigQuery after Hadoop migration with pruning-aware rewrites, partitioning/clustering alignment, typed extraction, and regression gates for stable spend.
- Hive to BigQuery - Tune BigQuery after Hive migration with pruning-aware rewrites, partitioning/clustering alignment, typed extraction, and regression gates for stable spend.
- Impala to BigQuery - Tune BigQuery after Impala/Hadoop migration with prune-first rewrites, partitioning/clustering, typing strategy, and regression gates to keep spend predictable.
- Impala to Snowflake - Tune Snowflake after Impala migration with pruning-aware rewrites, clustering alignment, bounded MERGE scopes, warehouse isolation, and regression gates.
- Netezza to BigQuery - Tune BigQuery after Netezza migration with pruning-aware rewrites, partitioning/clustering alignment, materializations, and regression gates for stable spend.
- Oracle to BigQuery - Tune BigQuery after Oracle migration with rewrites, partitioning/clustering alignment, materializations, and regression gates for predictable spend.
- Redshift to BigQuery - Tune BigQuery after Redshift migration with pruning-aware rewrites, partitioning/clustering, and regression gates for predictable costs and stable performance.
- Redshift to Snowflake - Tune Snowflake after Redshift migration with pruning-aware rewrites, bounded MERGE scopes, evidence-based clustering, warehouse isolation, and regression gates.
- Snowflake to BigQuery - Tune BigQuery post-Snowflake migration with pruning rewrites, partitioning/clustering, slot strategy, and regression gates for stable speed and spend.
- Spark SQL to BigQuery - Tune BigQuery after Spark SQL migration with rewrites, partitioning/clustering alignment, materializations, and regression gates for stable spend.
- Teradata to BigQuery - Tune BigQuery after Teradata migration with pruning rewrites, partitioning/clustering, slot strategy, and regression gates for stable speed and spend.
- Teradata to Snowflake - Tune Snowflake after migrating from Teradata with pruning-aware rewrites, bounded MERGE scopes, clustering, warehouse isolation, and regression gates.
Review points
- Partitioning, clustering, pruning, and scan behavior
- Runtime, cost, and concurrency baselines
- Materialization and pre-aggregation decisions
- Regression gates for critical reports and jobs
Acceptance criteria
A performance tuning & optimization page is complete when the migration team can identify source assets, understand conversion assumptions, review unsupported or ambiguous constructs, run validation checks, and decide whether the workload is ready for cutover.
For each related path, confirm that the child page explains what changes, how conversion works, which patterns are supported, what can drift, and which evidence is required before production traffic moves to the target platform.