When data engineers pull large result sets from Teradata today, the bottleneck usually isn't the database—it's the wire. JDBC, the protocol that almost every analytics tool uses to talk to SQL databases, was designed in a world where moving a few thousand rows was a big deal. It reads one row at a time, on a single thread, no matter how many CPU cores you have available.
Apache Arrow Flight SQL changes that. Instead of row-by-row retrieval over a single connection, it streams data as compressed columnar blocks over multiple parallel gRPC channels simultaneously. The result is a throughput profile that looks nothing like JDBC.
We ran a structured benchmark series with Teradata Cloud—across all supported CSPs (AWS, Azure, and Google Cloud)—to produce sizing guidance that customers can act on. Our testing showed improvement of ~15–30× , with some testing reaching a 47–84× gain.1
The protocol stack, briefly
Three open standards compose the stack. Apache Arrow defines an in-memory columnar format that virtually every modern analytics framework already understands natively—Spark, pandas, DuckDB, Polars, and dozens of others. Apache Arrow Flight adds a transport layer using gRPC, enabling multiple parallel data streams over a single connection. Apache Arrow Flight SQL is the final layer, adapting that transport to interact with SQL databases—letting clients issue queries and receive results as Arrow batches rather than JDBC rows.
The Teradata Arrow Flight SQL Connector Server sits in front of a Teradata database and exposes this interface to any compatible client. Our testing showed that a client that previously used JDBC gets the same query results back; they just arrive roughly 15 to 84 times faster for large reads, depending on hardware tier.1
What we measured
The benchmark compared three read paths—single-stream JDBC, single-stream Arrow, and multi-stream Arrow—across standard cloud instances on all three major cloud providers, and then on a higher-tier AWS configuration. We also measured upload performance and a single-stream query path used for ordered results.
Standard hardware = 2× 8 vCPU/32 GB driver nodes against a 2-node Teradata database. Higher-tier = 3× m5n.8xlarge drivers against 2× r6id.12xlarge DB nodes (AWS). JDBC is a single-stream path and is hardware-independent.
The standard hardware result is the practically important one for most customers: two driver nodes of modest size (8 vCPU, 32 GB) delivers 270–350 MB/s of sustained throughput at up to 20 concurrent users, on any cloud. That's roughly 15–30× JDBC in the standard configuration.
Higher performance was achieved with beefier instances; but costs more to run. Please evaluate your own needs on financial cost vs performance.
All configurations use a 2-node Teradata database. Gains come primarily from upgrading the DB instance (r6id.12xlarge), not just driver nodes. Driver CPU plateaus near 40%—the bottleneck is Teradata AMP I/O.z
Key insight: Adding more Arrow driver nodes has diminishing returns once the Teradata database becomes the I/O bottleneck. If you need more throughput, upgrade the database instance first. Driver CPU plateaus near 40%—the connector is waiting on the database, not the other way around.
Cross-cloud consistency
One question we wanted to answer cleanly: does Arrow Flight SQL performance vary meaningfully between AWS, Azure, and GCP when running equivalent instance types? The short answer is no—results are consistent within a normal measurement range across all three providers.
2× standard driver nodes (8 vCPU/32 GB) against a 2-node Teradata database.
Recommended sizing
The table below gives starting-point configurations for each cloud. These cover the Arrow driver nodes
| Cloud | Driver nodes | Instance type |
|---|---|---|
| AWS | 2 nodes | m5n.2xlarge (8 vCPU / 32 GB) |
| Azure | 2 nodes | D8s v5 (8 vCPU / 32 GB) |
| GCP | 2 nodes | c3-standard-8 (8 vCPU / 32 GB) |
Memory configuration matters more than node count. 16 GB of direct memory per driver node is the sweet spot. 8 GB is the functional minimum—2 GB fails outright at 5 concurrent sessions. Counterintuitively, 64 GB is 5% – 23% slower due to Netty buffer fragmentation. Use the unpooled Netty allocator for best results at high concurrency.
Where Arrow Flight SQL is not faster
The 47 – 84× advantage is real—but it applies specifically to the parallel read path. Two other paths behave differently, and it's worth understanding both.
Uploads (doPut)
Uploads use a single stream. There is no multi-stream write equivalent, so the goal here is parity with JDBC—not improvement. Single-session uploads reach near-parity at 1 GB (about 1.4% overhead). The practical constraint is on the database side: concurrent large uploads (≥449 MB across 5+ sessions) hit Teradata journal overflow in both Arrow and JDBC. This is a database-level limit, not something the connector can work around.
Upload best practices: Batch ≤20K rows per transaction, commit every ≤300K rows, and keep individual session data under ~100 MB. For large data loads, limit concurrent sessions to 1–3.
Single-stream direct query
Certain queries—those using ORDER BY, for example—take a direct query path that uses a single stream. On this path, Arrow Flight SQL runs about 10–15% slower than direct JDBC. The server converts a JDBC result set to Arrow format and adds a gRPC/TLS hop, with no parallel stream to offset that overhead. The parallel read path's advantage does not apply here.
Single-stream direct query: Arrow vs. JDBC
| Result set size | Arrow Flight SQL (MB/s) | JDBC (MB/s) |
|---|---|---|
| 100 MB | 30.4 | 33.8 |
| 500 MB | 39.9 | 46.2 |
| ~780 MB | 40.3 | 47.5 |
Direct query path (e.g., queries with ORDER BY). Arrow adds a conversion and gRPC/TLS hop with no parallel offset—JDBC wins narrowly here. The 47–84× advantage applies only to the parallel multi-stream read path.
Getting started
For most customers, the right entry point is two driver nodes on standard instances with 16 GB of direct memory per node and one stream per node. This configuration doubled throughput versus a single driver node in testing, eliminated out-of-memory failures at all tested concurrency levels, and costs under $700/month on any major cloud before reserved pricing discounts.
|
Recommended config 2 driver nodes · 1 stream/node · 16 GB direct memory · 8 GB Java heap |
Expected read throughput 270–350 MB/s sustained, stable through 20 concurrent users |
|
vs. JDBC (standard hardware) ~15–30× faster on parallel reads; parity on uploads; ~10–15% slower on single-stream direct query |
Scaling path Upgrade Teradata DB instance first—driver nodes won't help past the DB I/O ceiling (~870 MB/s) |
Download a copy of the performance benchmark summary and sizing recommendation datasheet. The full benchmark dataset and raw test results are available to Teradata customers and partners through the standard documentation channels. If you're evaluating the Arrow connector for a specific workload, reach out to your Teradata account team—we can map these results to your environment.
1. Performance results may vary. Benchmarks were conducted in a specific test environment and may not reflect results in your infrastructure.
Teradata Fabric · Arrow Flight SQL Server · Benchmark conducted on Teradata Cloud Active Compute across AWS, Azure, and GCP. Standard driver instances: m5n.2xlarge (AWS), Standard_D8s_v5 (Azure), c3-standard-8 (GCP). Higher-tier: 3× m5n.8xlarge drivers, 2× r6id.12xlarge DB (AWS). Cloud pricing as of June 2026; reserved/committed-use discounts of 30–60% apply. The 47–84× JDBC comparison was measured on the higher-tier configuration.