Benchmarks — Teradata vs Azure Performance Comparison¶

Audience: Performance engineers, architects, and decision-makers evaluating whether Azure can match Teradata's workload performance. This document provides benchmark methodology, representative results, cost-per-query analysis, and honest assessment of where each platform excels.

1. Benchmark methodology¶

1.1 Approach¶

All benchmarks use representative workloads modeled after real enterprise Teradata environments. These are not synthetic TPC-style benchmarks — they reflect actual query patterns, data distributions, and concurrency levels.

Test categories:

1.2 Environment specifications¶

1.3 Data model¶

Star schema with:

• Fact table: 2 billion rows (orders), ~200 GB compressed
• Dimension tables: customers (50M rows), products (2M rows), regions (5K rows), dates (30 years)
• Teradata PI: customer_id on fact table
• Azure distribution: HASH(customer_id) on Synapse, ZORDER BY (customer_id) on Databricks

2. MPP join performance¶

2.1 Two-table join (fact + dimension)¶

-- Query: Join orders (2B rows) with customers (50M rows)
SELECT
    c.customer_segment,
    COUNT(*) AS order_count,
    SUM(o.amount) AS total_revenue
FROM orders o
INNER JOIN customers c ON o.customer_id = c.customer_id
WHERE o.order_date BETWEEN '2024-01-01' AND '2024-03-31'
GROUP BY c.customer_segment;

Analysis: Teradata's cold-run advantage comes from PI-based co-located joins (no data shuffle). Databricks and Synapse match or beat Teradata on warm runs due to result caching and columnar efficiency.

2.2 Multi-way join (fact + 4 dimensions)¶

-- Query: Star schema join with all dimensions
SELECT
    d.calendar_year,
    d.calendar_quarter,
    r.region_name,
    c.customer_segment,
    p.product_category,
    COUNT(*) AS order_count,
    SUM(o.amount) AS total_revenue,
    AVG(o.amount) AS avg_order_value
FROM orders o
INNER JOIN customers c ON o.customer_id = c.customer_id
INNER JOIN products p ON o.product_id = p.product_id
INNER JOIN regions r ON o.region_id = r.region_id
INNER JOIN dates d ON o.order_date = d.calendar_date
WHERE d.calendar_year = 2024
GROUP BY 1, 2, 3, 4, 5
ORDER BY total_revenue DESC;

Analysis: Teradata's PI only co-locates one join. The remaining 3 dimensions require redistribution, reducing the PI advantage. Azure platforms broadcast small dimensions, which is often faster.

2.3 Large table self-join¶

-- Query: Customer repeat order analysis (self-join on orders)
SELECT
    o1.customer_id,
    COUNT(DISTINCT o1.order_id) AS first_orders,
    COUNT(DISTINCT o2.order_id) AS repeat_orders
FROM orders o1
LEFT JOIN orders o2
    ON o1.customer_id = o2.customer_id
    AND o2.order_date > o1.order_date
    AND o2.order_date <= DATE_ADD(o1.order_date, 30)
WHERE o1.order_date BETWEEN '2024-01-01' AND '2024-01-31'
GROUP BY o1.customer_id;

Analysis: This is where Teradata genuinely excels. Self-joins on the PI column are fully co-located. Azure platforms must shuffle data for this pattern. With result caching, Databricks catches up on warm runs.

3. Large aggregation benchmarks¶

3.1 Simple aggregation (high cardinality GROUP BY)¶

-- Query: Revenue by date, region, segment, category (4-level GROUP BY)
SELECT
    order_date,
    region_id,
    customer_segment,
    product_category,
    COUNT(*) AS order_count,
    SUM(amount) AS revenue,
    SUM(discount) AS discounts
FROM orders_enriched  -- Pre-joined view/table
WHERE order_date BETWEEN '2024-01-01' AND '2024-12-31'
GROUP BY 1, 2, 3, 4;

3.2 Window function aggregation¶

-- Query: Running total and rank by customer
SELECT
    customer_id,
    order_date,
    amount,
    SUM(amount) OVER (PARTITION BY customer_id ORDER BY order_date) AS running_total,
    RANK() OVER (PARTITION BY customer_id ORDER BY amount DESC) AS amount_rank
FROM orders
WHERE order_date BETWEEN '2024-01-01' AND '2024-06-30'
QUALIFY amount_rank <= 5;

4. Concurrent query handling¶

4.1 Test setup¶

Simulate production load with mixed workload:

• 10 complex BI dashboard queries (5-30s each)
• 50 ad-hoc analyst queries (1-10s each)
• 5 ETL batch queries (30-120s each)
• Running simultaneously for 30 minutes

4.2 Results¶

Analysis: Databricks achieves better concurrency by dedicating separate SQL warehouses per workload tier. Each warehouse auto-scales independently. Teradata's TASM manages contention well but everything shares one system. Synapse workload groups are effective but the shared DWU pool shows more contention.

4.3 Scaling behavior¶

Databricks scales better at high concurrency because auto-scaling adds clusters. Teradata's fixed hardware reaches saturation. Synapse can be scaled (higher DWU) but requires manual intervention.

5. Cost-per-query analysis¶

5.1 Methodology¶

Calculate the effective cost of running each query type:

Cost per query = (Hourly compute cost * Query runtime in hours) / Queries per hour

5.2 Results¶

Calculation basis:

• Teradata: $5M/year / 8,760 hours = $571/hour (always running)
• Databricks: Large warehouse at $80/hour (when running)
• Synapse: DW3000c at $100/hour (when running)

Key insight: Teradata's high cost-per-query stems from paying for the full system 24/7 regardless of utilization. Azure's pay-per-use model (especially with auto-pause) dramatically reduces cost per query.

5.3 Monthly cost comparison at different utilization levels¶

Azure wins at every utilization level, but the advantage is most dramatic at low-medium utilization where Teradata's fixed cost is spread over fewer queries.

6. ETL/ELT throughput benchmarks¶

6.1 Bulk load performance¶

6.2 Incremental load (CDC)¶

7. Migration timeline benchmarks¶

Based on real-world migrations:

7.1 Migration effort by estate size¶

7.2 Conversion rates¶

8. Performance tuning guide¶

8.1 Closing the gap on Teradata-favored workloads¶

8.2 Where Azure outperforms without tuning¶

9. Executive summary¶

Bottom line: Azure matches or beats Teradata on most benchmarks, with the notable exception of cold-start PI-colocated join performance. The cost-per-query advantage is overwhelming. Organizations that tune their Azure environment properly (distribution, Z-ORDER, warehouse sizing) will see equivalent or better performance at 50-70% lower cost.

10. Related resources¶

• TCO Analysis — Full cost comparison
• Why Azure over Teradata — Strategic context
• Workload Migration — Workload management design
• Best Practices — Performance tuning recommendations
• Teradata Migration Overview — Original migration guide
• Databricks Photon: https://docs.databricks.com/runtime/photon.html
• Synapse performance tuning: https://learn.microsoft.com/azure/synapse-analytics/sql-data-warehouse/sql-data-warehouse-best-practices

Maintainers: csa-inabox core team Last updated: 2026-04-30