FastBCP 1.2: Oracle ADBC Export and RAC Scaling
FastBCP 1.2 adds an Oracle export path backed by ArpeOracle, ARPE.IO's ADBC Driver for Oracle wire-protocol. The driver communicates through Oracle TNS and TTC and returns columnar Apache Arrow data to FastBCP for Parquet generation, without an Oracle client library in the path.
The release brings this path into the same parallel export model already used by FastBCP across different database engines and operating systems. Nine runs illustrate that range: Windows and Linux, standalone Oracle and Oracle RAC, SQL Server and PostgreSQL, narrow and wide tables, and degrees of parallelism from 1 to 64. On Oracle RAC, the measured export time fell from 27.7 seconds at DOP 1 to 4.8 seconds at DOP 8.
What changed in FastBCP 1.2
This article focuses on the integrated Oracle ADBC export path. FastBCP 1.2 combines three parts of the ARPE.IO data stack:
- ArpeOracle connects to Oracle through its TNS and TTC wire protocols, without OCI or Oracle Instant Client.
- Apache Arrow Database Connectivity (ADBC) supplies a columnar interface between the database driver and FastBCP.
- FastBCP partitions the source workload, runs multiple extraction sessions, and writes the resulting Arrow batches to Parquet.
In FastBCP 1.2.0.0 a new Oracle connection path is possible using the ArpeOracle ADBC driver, selected with --connectiontype "adbc_oracle".
All nine results in this article use ARPE.IO ADBC Drivers. The performance chart does not mix ADBC measurements with FastBCP's existing native or vendor-driver paths:
| Source | ARPE.IO ADBC Driver | Wire protocol | Parallel method shown |
|---|---|---|---|
| Oracle | ArpeOracle | TNS + TTC | Rowid |
| SQL Server | ArpeMSSQL | MS-TDS 7.4 | RangeId |
| PostgreSQL | ArpePgSQL | Frontend/Backend v3 | Ctid |
ADBC complements FastBCP's existing drivers
The ADBC paths extend FastBCP's connectivity; they do not replace the native and vendor drivers already embedded in the product. Those established drivers remain available for database extraction to CSV, JSON, XLSX, and Parquet.
This gives FastBCP two complementary connection strategies:
- use an ARPE.IO ADBC Driver for the high-performance Arrow-to-Parquet path when one is available for the source;
- use the existing native or vendor driver for CSV, JSON, XLSX, or Parquet, including databases for which an ADBC path is not yet available.
The command-line workflow, parallel extraction methods, output naming, and destination handling remain part of FastBCP in both cases. Teams can therefore adopt the ADBC path where it adds value without losing the broader source and file-format coverage already available in FastBCP.
How parallel Oracle export works
For Oracle, FastBCP can divide a table into independent ranges. At DOP 8, the measured run executed eight range queries and wrote eight Parquet chunks in parallel.
On a standalone database, the sessions use one Oracle instance. With Oracle RAC and an appropriately configured service, Oracle can distribute new connections across the instances offering that service. FastBCP supplies the concurrent extraction sessions; RAC connection load balancing supplies the multi-instance routing. This makes the two parallel models complementary for large export workloads.
A sanitized version of the measured DOP 8 command is:
.\FastBCP.exe `
--connectiontype "adbc_oracle" `
--server "[ORACLE_SCAN_OR_HOST]:1521/[SERVICE_NAME]" `
--user "[USER]" `
--password "[PASSWORD]" `
--sourceschema "[SCHEMA]" `
--sourcetable "[TABLE]" `
--fileoutput "{sourcetable}.parquet" `
--directory "[OUTPUT_DIRECTORY]" `
--parquetcompression "Zstd" `
--parallelmethod "Rowid" `
--paralleldegree 8 `
--merge false
Use a secret store or environment-based credential injection in automation rather than placing the password in shell history.
Oracle RAC: DOP 1 versus DOP 8
The two RAC logs use the same FastBCP version, Windows build, Oracle 19c source, table, row and column counts, Zstd compression, output location, and reported output size. The parallel method changes from None at DOP 1 to Rowid at DOP 8.
| Metric | DOP 1 | DOP 8 | Observed change |
|---|---|---|---|
| FastBCP version | 1.2.0.0 | 1.2.0.0 | Same |
| Client OS | Microsoft Windows 10.0.20348 | Microsoft Windows 10.0.20348 | Same |
| Source | Oracle 19c RAC | Oracle 19c RAC | Same |
| Rows | 14,945,679 | 14,945,679 | Same |
| Columns | 44 | 44 | Same |
| Parquet compression | Zstd | Zstd | Same |
| Output size | 694.69 MB | 694.69 MB | Same |
| Total elapsed time | 27.695 s | 4.851 s | 82.5% lower |
| Final throughput | 539,643 rows/s | 3,080,788 rows/s | 5.71× |
| Final cell throughput | 23,744,327 cells/s | 135,554,707 cells/s | 5.71× |
| Reported disk write throughput | 25.10 MB/s | 143.78 MB/s | 5.73× |
The DOP 8 run completed in approximately one-sixth of the DOP 1 time. Final throughput increased from 539,643 to 3,080,788 rows/s while the reported Parquet output size remained identical. The measured 5.71× acceleration covers the complete path from Oracle reads through Arrow batches, Zstd compression, and local Parquet writes.
FastBCP 1.2 across engines, platforms, and workloads
The nine completed runs show how FastBCP adapts its export strategy to different environments:
- from 7.7 million to 600 million rows;
- from 9 to 181 columns;
- Windows and Linux clients;
- Oracle standalone, Oracle RAC, SQL Server, and PostgreSQL sources;
- source-specific
Rowid,RangeId, andCtidpartitioning; - DOP values from 1 to 64;
- compressed and uncompressed Parquet output.
| Source and workload | Client OS | FastBCP | DOP / method | Shape | Total time | Final cells/s |
|---|---|---|---|---|---|---|
| Oracle 19c standalone, wide table | Red Hat Enterprise Linux 8.10 | 1.2.0.0 | 8 / Rowid | 7,704,183 × 181 | 9.714 s | 143,548,077 |
| Oracle 19c RAC, test table | Microsoft Windows 10.0.20348 | 1.2.0.0 | 1 / None | 14,945,679 × 44 | 27.695 s | 23,744,327 |
| Oracle 19c RAC, test table | Microsoft Windows 10.0.20348 | 1.2.0.0 | 8 / Rowid | 14,945,679 × 44 | 4.851 s | 135,554,707 |
| Oracle 19c standalone, wide table | Microsoft Windows 10.0.14393 | 1.2.0.0 | 4 / Rowid | 7,704,183 × 181 | 33.519 s | 41,601,766 |
SQL Server 2022, TPC-H SF100 lineitem, uncompressed | Microsoft Windows 10.0.20348 | 1.2.0.0 | 64 / RangeId | 600,037,902 × 17 | 19.879 s | 513,116,440 |
SQL Server 2022, TPC-H SF100 lineitem, Zstd | Microsoft Windows 10.0.20348 | 1.2.0.0 | 64 / RangeId | 600,037,902 × 17 | 20.271 s | 503,197,062 |
SQL Server 2022, orders | Microsoft Windows 10.0.26200 | 1.2.0.0 | 16 / RangeId | 15,000,000 × 9 | 2.498 s | 54,025,850 |
PostgreSQL 15.15, orders | Linux Mint 21.1 | 1.2.0.0 | 16 / Ctid | 15,000,000 × 9 | 3.691 s | 36,571,109 |
PostgreSQL 17.2, orders | Microsoft Windows 10.0.26200 | 1.2.0.0 | 16 / Ctid | 15,000,000 × 11 | 3.210 s | 51,396,007 |
The chart intentionally brings these different situations together. It is not a database-engine ranking: it shows that the same FastBCP release can apply a source-appropriate extraction method, scale the worker count, and produce Parquet across a broad range of workloads.
What these runs demonstrate
- One export workflow across several databases. The same FastBCP CLI drives Oracle, SQL Server, and PostgreSQL exports.
- Database-aware parallelism.
Rowidpartitions Oracle tables,RangeIddivides suitable SQL Server keys, andCtidpartitions PostgreSQL heap storage. - Standalone and clustered sources. FastBCP can use one Oracle instance or open multiple sessions through an Oracle RAC service.
- Windows and Linux execution. The supplied runs completed on both platforms with FastBCP 1.2.
- Adaptation to row shape and volume. The examples range from 9-column analytical tables to a 181-column Oracle table, and up to 600,037,902 rows.
- Configurable output trade-offs. The SQL Server SF100 pair shows the same workload written with uncompressed Parquet and Zstd using the same DOP 64 extraction plan.
These are raw single-run observations from different environments, included to show FastBCP's operating range. The Oracle RAC DOP 1 and DOP 8 pair is the direct scaling comparison; the other runs are practical capability examples rather than a controlled cross-engine benchmark.
Trying the Oracle ADBC path
- Confirm the binary reports FastBCP
1.2.0.0. - Select the new path with
--connectiontype "adbc_oracle". - Use
Rowidwith a DOP appropriate for the source and client capacity. - On Oracle RAC, connect through the service intended to distribute export sessions.
- Validate the reported row count and generated Parquet schema before moving the configuration into production.
Next on the ADBC roadmap
The 2026 roadmap includes additional ARPE.IO ADBC Drivers designed around direct database wire protocols:
- an ADBC Driver for IBM Db2 for DB2 LUW, IBM i (iSeries), and z/OS (zSeries);
- an ARPE.IO ADBC Driver for Teradata;
- an ARPE.IO ADBC Driver for Netezza.
These planned drivers are intended to extend FastBCP's high-performance Parquet extraction path to more enterprise database platforms. They will complement the native and vendor drivers that FastBCP already provides for these sources.
We also plan to evaluate third-party ADBC integrations. The current ADBC driver ecosystem lists Driver Foundry implementations for Snowflake, Databricks, and Presto, along with a vendor-maintained Exasol driver. Their inclusion in FastBCP will depend on technical validation across packaging, authentication, type coverage, stability, and supported platforms.
Conclusion
FastBCP 1.2 brings ARPE.IO's ADBC driver for Oracle wire-protocol into the Parquet export pipeline. In the supplied Oracle RAC test, combining ArpeOracle with eight parallel sessions reduced total elapsed time from 27.7 seconds to 4.8 seconds for a 14.9-million-row, 44-column table.
The broader set of runs shows the larger design goal behind the release: one export tool that adapts to the database engine, operating system, table shape, output compression, and available parallelism. From a wide Oracle table on Linux to a 600-million-row SQL Server export on Windows, FastBCP keeps the workflow consistent while selecting source-specific extraction strategies.
FastBCP 1.2 is therefore both a concrete Oracle milestone and the foundation for broader ADBC coverage. The next step is to expand the high-performance Parquet path with additional ARPE.IO ADBC wire-protocol drivers for Db2, Teradata, and Netezza, while evaluating selected Driver Foundry and vendor ADBC Drivers for platforms such as Snowflake, Databricks, Presto, and Exasol.