ADBC: a database connectivity standard where the result set is Arrow

The API is stable, the libraries are not, and that split matters

ADBC is an API standard, version 1.0.0, for database access libraries called drivers, in C, Go and Java, that uses Arrow for result sets and query parameters.

The status section draws a distinction that a reader should not skip. ADBC versions the API standard and the implementing libraries separately. The API standard at version 1.0.0 is considered stable, but enhancements may be made. Libraries are under development.

That is an unusual and useful thing for a project to tell you plainly. It means you can design against the API surface knowing the shape of it will not move, while knowing that the individual drivers are still moving underneath. For a team evaluating a database integration, that is the difference between committing to a contract and committing to an implementation, and only the first is a guarantee.

The release history reflects the same pattern. The tags are apache-arrow-adbc-25-rc0 from 2026-09-21, apache-arrow-adbc-24 from 2026-07-24, and apache-arrow-adbc-24-rc1 from 2026-07-23. A release candidate and a final release of the same library line, tagged days apart, is what a project in active development looks like.

The audience is a data platform engineer who is already using Arrow, and the primary language of the repository is recorded as C#, with implementations in C, Go and Java and directories for Python, R, Ruby, Rust, JavaScript and more.

The homepage is arrow.apache.org/adbc, the licence is Apache-2.0, and the last push to the repository was on 2026-10-22.

Why the result set format is the whole point

The problem ADBC solves is stated in the second paragraph of the README, and it is worth reading literally.

Instead of writing code to convert to and from Arrow data for each individual database, applications can build against the ADBC APIs and link against drivers that implement the standard.

So the motivation is a conversion tax. If your application works in Arrow and your database driver returns row-oriented results, every query needs a conversion step that you write, and you write it again for the next database. ADBC moves that conversion into the driver, where it belongs, and makes it a one-time cost per database rather than a per-application cost.

The scope is deliberately narrow, and the README says so. Like JDBC and ODBC, the goal is to provide a generic API for multiple databases. ADBC, however, is focused on bulk columnar data retrieval and ingestion through an Arrow-based API, rather than attempting to replace JDBC and ODBC in all use cases. Hence, ADBC is complementary to those existing standards.

That last sentence is the framing to keep. This is not a better JDBC. It is a different tool for a different access pattern, and the project says so rather than claiming to take over the whole space.

The driver manager completes the picture. Additionally, a JDBC and ODBC style driver manager is provided. It implements the ADBC APIs but dynamically loads drivers and dispatches calls to them, so an application can be written once against ADBC and pointed at different databases at runtime.

ADBC and Flight SQL solve opposite halves of the Arrow problem

The README positions ADBC against Arrow Flight SQL, and the distinction is the kind that gets blurred in conference talks.

Both are Arrow-based ways to work with databases. The difference is what they are. Flight SQL is a protocol defining a wire format and network transport. ADBC is a client API specification for wrapping existing database protocols, which could be Arrow-native or not.

So Flight SQL requires a database to specifically implement support for it. ADBC does not. ADBC sits on the client side and can talk to a database that knows nothing about Arrow, and it can also talk to one that is Arrow-native.

The README's summary is that together, ADBC and Flight SQL offer a fully Arrow-native solution for clients and database vendors. That is the division of labour: a client application uses ADBC, the driver handles the translation, and a database vendor who wants to avoid that translation implements Flight SQL and the ADBC driver over it becomes nearly a pass-through.

For a team choosing between them, the question is where the Arrow data is created. If the database can be modified, implementing Flight SQL server side moves the work to the vendor and keeps the client path clean. If the database cannot be modified, ADBC is the only option, and the conversion happens in the driver.

The introductory blog post linked from the README, Introducing Arrow ADBC, is the reference for the design rationale, and the Flight SQL format documentation is linked for the wire format side.

The header file is the API, and the languages are separate efforts

The documentation section is short and points at two specific things. The core API definitions can be read in adbc.h, and the user documentation is at the Arrow ADBC site.

That adbc.h is the specification in practice. For a C-flavoured standard, the header is the contract, and it is the first thing an implementer reads. The fact that the README points at it rather than at a prose API description is a useful signal about how the project expects people to work with it.

The repository layout shows the scale of the undertaking. There are directories for c/, go/, java/ and csharp/ as the three languages the README names, and then python/, r/, ruby/, rust/, javascript/, glib/ and r/ as well, plus testing/ for the conformance suite, docs/, ci/ and dev/. A compose.yaml at the root defines the build matrix, and and per-language build scripts under ci/scripts/.

The compose file is a good illustration of how the CI works. The C# service builds on the.NET SDK image, mcr.microsoft.com/dotnet/sdk:10.0, with the source bind-mounted at /adbc and a pack script as the command. The C and C++ service builds against a Clang image with a project specific Dockerfile, and it passes extra compiler flags through an environment variable, ADBC_CMAKE_ARGS, holding flags for documentation warnings and a checkin warning level. The build scripts live in ci/scripts/ and are invoked with the source directory as an argument, which keeps the matrix readable.

The listing also carries an r/ directory, so the R implementation sits alongside the others in the tree even though the README names only C, Go and Java as the languages the standard covers.

Where ADBC is the wrong tool

The first wrong-tool case is a transactional application. The README is explicit that ADBC is focused on bulk columnar data retrieval and ingestion, and it does not attempt to replace JDBC or ODBC in all use cases. If your application issues thousands of small statements a second and cares about prepared statement reuse and per-row semantics, ADBC is the wrong shape, and no amount of driver maturity changes that.

The second case is a team that needs a working driver now. The API standard is stable, but the libraries are under development, and the release history shows release candidates a day apart from a final release. The driver status page is linked from the README precisely because the answer to is driver X ready is per database and per language. Adopting ADBC as the sole database access layer for a production service means tracking that matrix, not just pinning a version.

The third case is a team that has settled on a single database and a good native client. The value of a generic API comes from having more than one target, and from the conversion tax being paid once. If you talk to exactly one database through a driver that already returns Arrow, a thin client of your own is less machinery than adopting a standard plus a driver manager plus the driver manager's own driver loading rules.

There is a cost that is easy to understate. A driver manager that dynamically loads drivers and dispatches calls to them is convenient, and it is also another layer where an error surfaces as a failure to load rather than as a database error. The C and C++ path additionally depends on a compiler toolchain, which the compose file shows in some detail.

What you get in exchange is the ability to move Arrow data out of a database without writing the conversion, and a standard that a database vendor can implement once for every client language.

Editorial conclusion

ADBC suits a data platform that moves Arrow tables between a database and a columnar engine, because the columnar data format crosses the driver boundary instead of stopping at it, and the driver manager lets one application bind different databases without changing its code. It does not suit an application that issues many small transactional queries, since the design is explicitly focused on bulk columnar retrieval and ingestion, and it does not suit a team that needs a mature driver today, because the README states the libraries are still under development even though the API standard is stable. Before adopting, read the driver status page for your database, and check the changelog because the standard and the libraries are versioned separately.

Frequently asked questions

Official sources

1. apache/arrow-adbc on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases