Exasol says you should migrate from Teradata. After more than 20 years working with Teradata, I seriously question some of their arguments.
Exasol promotes its guide, 3 Reasons to Migrate from Teradata, through a public migration page. This article examines that page and Exasol’s published Helsana customer story.
I have nothing against Exasol. It is a capable analytical database, and I am sure it can outperform Teradata for certain workloads.
My concern is how far the published marketing statements and customer results support a broader recommendation to migrate.
Let's look at a few examples.
Each box below summarizes a position or result stated on the linked public Exasol page, followed by my assessment. This is a critique of those public sources, not a verified review of the full ebook. Questions about tuning, ingestion, AI and workload management are my evaluation criteria; they should not be read as claims that Exasol says Teradata lacks those capabilities.
1. Self-tuning and the role of the Primary Index
My assessment
To assess the cost claim, I would compare the administration effort and automation available in the specific environments. Teradata has had a sophisticated cost-based optimizer for decades, with statistics-management and optimization capabilities that should be evaluated for the product and release in use.
Physical design also matters to both cost and performance. Teradata’s Primary Index is not simply another access-path index: for primary-indexed tables, it is fundamental to data distribution and parallel processing.
2. Loading results do not establish an ingestion limitation
My assessment
A shorter batch load is a useful customer outcome, but it does not establish that Teradata’s architecture prevents continuous ingestion. The phrase “data warehouse updates” is also ambiguous: it may refer to development or release cycles rather than the frequency of data ingestion. The public story does not resolve that distinction.
I have worked with Teradata environments processing enormous amounts of data through complex ETL pipelines.
Continuous ingestion is primarily an architectural question involving source systems, streaming infrastructure, transformation logic, and target database capabilities.
Kafka, NiFi, and Teradata can absolutely be part of a near-real-time architecture. The delivery, ordering, replay, transaction and recovery requirements still need to be designed and tested.
3. MPP performance needs a complete workload comparison
My assessment
For certain analytical workloads, Exasol can outperform Teradata.
Teradata has also been an MPP database since its beginnings. My assessment is that architectural labels alone cannot establish which platform will perform better for a particular production workload.
The real question is not whether an analytical query runs faster when its working set benefits from memory-oriented execution.
The real question is how the platform behaves when hundreds or thousands of users compete with large batch transformations, continuous data ingestion, complex joins, and business-critical reporting.
What happens under memory pressure?
What happens when intermediate results become enormous?
What happens during month-end processing?
And what does the infrastructure cost when you have to guarantee all these workloads simultaneously?
4. Future readiness needs a concrete AI assessment
My assessment
My assessment of future readiness would include ClearScape Analytics and Teradata’s Python integration, Native Object Store, and the broader VantageCloud ecosystem. Capabilities and availability should be checked for the specific product, release and deployment being compared.
A fair comparison should test the actual AI use cases, model integration, data access, governance and operating costs. Support for programming languages or UDFs alone does not establish that one platform is superior.
The Helsana success story: what do the numbers establish?
My assessment
In its Helsana customer story, Exasol reports 5 to 10 times better performance and a 65% reduction in license and maintenance costs. These are vendor-reported customer outcomes; the 65% figure refers to those fees, not a demonstrated 65% reduction in total ownership cost.
Impressive results, certainly.
But what exactly was compared?
Which database versions? Which hardware? Which workloads? Which optimizations?
The published benchmark table even shows different query counts across the compared environments.
For example, the public story’s small-query table lists 5,000 queries for Production B2C and 10,000 for Exasol. Different query counts can be legitimate in a throughput test. They do not, by themselves, invalidate a result—but the query mix, data, concurrency, hardware and measurement method are needed to interpret it fairly.
Without knowing whether the same workload was executed under comparable conditions, how can we draw general conclusions?
The same public story also describes over 600 users and end-of-day, weekend and month-end processing. Those are relevant enterprise requirements. My concern is how far a published customer result can be generalized, not whether that customer obtained value from the migration.
A successful customer migration is not proof that one database architecture is universally superior.
Complexity and enterprise workload management
My assessment
For me, a claim of greater flexibility raises practical questions about administration, development and workload control. Those need a concrete comparison of the proposed environments.
Teradata was designed to handle large, diverse enterprise workloads with predictable performance. Some of its design and administration choices reflect those requirements.
Data distribution, workload management, statistics, and physical database design are not simply unnecessary complications.
They are engineering mechanisms.
And Teradata's workload management capabilities, particularly TASM, deserve far more attention in any serious enterprise comparison.
Those mechanisms have an administration cost and are not a guarantee of good performance. They should be evaluated against the workload and service levels they are intended to protect.
I am not saying Teradata is always the right choice.
Licensing can be expensive. Poor database design can destroy performance. Some workloads may run more efficiently on Exasol, Snowflake, Databricks, or other platforms.
But replacing a mature enterprise data warehouse is not the same as migrating a collection of analytical queries.
The question to answer before recommending migration
Can the new platform execute the complete production workload, including ETL, concurrent reporting, data ingestion, and peak processing, while meeting the same SLAs at a lower total cost?
If the answer is yes, migration may make sense.
A useful comparison should also establish equivalent business results, operational responsibilities, recovery behavior and total costs over an agreed period.
If the answer is based primarily on selected benchmarks and marketing promises, I would be very careful.
A faster database does not automatically mean a better warehouse
A faster database does not automatically mean a better data warehouse.
I would genuinely like to hear from engineers with hands-on experience using both Exasol and Teradata.
Where does Exasol have a real architectural advantage, and where does Teradata remain stronger?
For a reproducible example of why loading method and transaction boundaries matter, see our Teradata MERGE loading benchmark. For a broader platform decision, read about our independent data platform assessment.
Deciding what to change in your data platform?
Compare optimisation, modernisation and migration against your workload and business requirements.