A few months ago, I published the article Teradata DB-e 20: OTF Performance, in which I said that, originally, Teradata used the Apache Iceberg and Delta Lake Java APIs to connect to the OTF tables. However, since March 2026, Teradata has been silently deploying a Native OTF connection that will completely replace the Java connection. Native OTF aims to improve performance when reading and writing to OTF tables, both Iceberg and Delta Lake tables.

In this post, I will explain Teradata’s Native OTF and how it enhances performance when using this engine to access OTF tables.

What is Teradata’s Native OTF?

Teradata refers to “Native OTF” as the proprietary C++ code it developed to connect to Apache Iceberg and Delta Lake tables. I.e., both OTF flavours are open source. Teradata uses a version of them that it adapted to its solution needs, and it doesn’t share as open-source code.

The main reason why Teradata uses C++ is that it is TPA-compliant. That’s to say, TPA stands for Trusted Parallel Architecture and refers to the nodes that comprise the Vantage database. A TPA-compliant code runs with higher concurrency than non-TPA-compliant code, such as user-provided functions, because it runs in parallel on all nodes.

To put it differently, Native OTF adapts to Teradata’s query processing, i.e., queries go to the Resolver, Parser, Optimiser, and AMP steps. So, Vantage performs better for queries running on OTF with this native connection, as it fully leverages Vantage’s built-in parallelism and doesn’t require as many steps to build a response.​

Notably, the native OTF solution does not introduce any syntax that differs from the Java implementation. Thus, anything you have already developed to work on your OTF tables from Vantage works the same. Furthermore, the features described in the article Teradata DB-e 20: OTF Performance and the performance recommendations remain valid, even though you will get an additional boost in performance with Native OTF.

Native vs. Java OTF

Even though the Native OTF is TPA-compliant and leverages Vantage’s built-in parallelism, this is not the only reason the Native OTF improves performance. Below, you have a table explaining all aspects where a C++-based connection provides better execution times.

Teradata’s Native OTF reduces Elapsed Time

Teradata Engineering built a native C++ reader and writer for Vantage OTF capabilities. Note that the critical factor for improving performance in Iceberg and Delta Lake is reading and writing quickly, as they drive the elapsed time. So, the Teradata C++ API reduces the elapsed time.

Apache released its first official C++ connector in September 2025, while Teradata had already significantly progressed in its connector. By March 2026, Apache Iceberg had released version 0.2.0.

Separately, Databricks doesn’t have any official C++ release for the Delta Lake tables.

So, for now, Teradata is the only vendor which can provide C++ read and write OTF capability.