Teradata’s 84× Arrow headline has a boundary: parallel reads only

Teradata’s new Arrow Flight SQL benchmark makes a striking claim: large parallel reads can run 15–30× faster than JDBC on standard cloud hardware, with a higher-tier AWS configuration reaching a 47–84× comparison. The useful part for data-agent teams is not the biggest multiplier. It is the vendor’s unusually explicit map of where that multiplier does—and does not—apply. Teradata’s benchmark article and its downloadable benchmark summary describe separate parallel-read, direct-query and upload paths.

Start with the standard configuration

The practical baseline used two Arrow driver nodes, each with 8 vCPUs and 32 GB of memory, against a two-node Teradata database. Teradata reports 270–350 MB/s of sustained throughput through 20 concurrent users across AWS, Azure and Google Cloud. Its recommended starting point is two drivers, one stream per node, 8 GB of Java heap and 16 GB of direct memory per node. The vendor says that configuration costs under $700 per month for the driver layer before reserved-use discounts.

That is the number teams should put into an initial capacity model. The 47–84× result came from higher-tier hardware: three m5n.8xlarge driver nodes and two r6id.12xlarge database nodes on AWS. The benchmark summary says throughput eventually became bound by Teradata AMP I/O rather than the connector; driver CPU plateaued near 40%. Adding connector nodes after that point is not the scaling move—upgrading the database is.

Split the acceptance test by execution path

The benchmark’s negative results matter for conversational analytics. Queries using ORDER BY can take a single-stream direct-query path. There, Arrow delivered 30.4–40.3 MB/s across the tested result sizes while JDBC delivered 33.8–47.5 MB/s. Teradata therefore measured Arrow at roughly 10–15% slower because the server adds JDBC-to-Arrow conversion plus a gRPC/TLS hop without parallelism to offset it. Those direct-query figures mean an agent returning a sorted answer should not inherit the parallel-read headline in a performance forecast.

Uploads also stay single-stream. At 1 GB, Arrow’s DoPut path came within 1.4% of JDBC rather than beating it. Five or more concurrent uploads of at least 449 MB triggered Teradata journal overflow in both protocols. The published guidance is to batch no more than 20,000 rows, commit at no more than 300,000-row intervals, keep a session near 100 MB, or limit large-load concurrency to one to three sessions.

The rollout decision

For a text-to-SQL or analytics agent, benchmark three result shapes separately: a large unordered extract, an ordered analytical answer and an upload/tool-write path. Record throughput, first-row latency, memory and database I/O for each. Arrow Flight SQL looks compelling when the workload can use parallel columnar retrieval; Teradata’s own evidence says it is not a universal JDBC replacement.

The results are vendor-run, and the full raw dataset is available only to Teradata customers and partners through its documentation channels. Treat the published numbers as sizing hypotheses, then reproduce them with the query shapes and concurrency your agents will actually generate.