Apache Arrow ADBC Just Listed My ODBC Bridge on Its Official Integrations Page — Seven Days After v0.1.0

As of this morning, the Apache Arrow ADBC documentation lists my project on its official Tools & Integrations page — adbcBridge, alongside DuckDB, Apache DataFusion, pandas, Polars and the rest of the ecosystem that works with the ADBC standard. I built adbcBridge for one reason — give every ODBC database an ADBC path — and there is no better place for it to be found than the page where people go to see what works with ADBC.

It took seven days from my first release to the listing. This is the short story of how that happened, what the entry actually says, and what it changes — plus the honest footnotes.

How a listing happens

The ADBC Drivers page says: open an issue with the details. So on August 31 I filed apache/arrow-adbc#4730 — name, what it drives, how it works, where the numbers live. The same evening, a member of the project replied: the Drivers page wasn't quite the right home for it, but — quote — it "makes a great addition to the Tools & Integrations docs page," with an invitation to open a PR and an offer to review it personally.

I opened PR #4733 that night: one entry, which I wrote to match the length and style of its neighbors, with a working Python snippet. It was reviewed and merged six hours after the invitation, by the same member who suggested it. Apache projects are not known for six-hour turnarounds; watching a maintainer choose to move that fast on my one-week-old project is its own kind of signal.

What the entry says

The listing describes adbcBridge exactly as I would want it described — because it describes it exactly as it is: an ADBC driver, written in C, that loads an ODBC driver and exposes it through the ADBC API, giving an ADBC path to databases that have an ODBC driver but no native ADBC one. And it shows the two lines that matter:

import adbc_driver_manager.dbapi as dbapi

conn = dbapi.connect(driver="odbc", db_kwargs={"uri": "Driver=SQLite3;Database=my.db;"})
with conn.cursor() as cur:
    cur.execute("SELECT 42 AS answer")
    print(cur.fetch_arrow_table())

That driver="odbc" is the whole pitch I have been making since Part 1: the standard ADBC driver manager, the standard DB-API surface, Arrow tables out — and behind it, whichever of the few hundred ODBC drivers your database ships. Db2, Oracle, Informix, Vertica, Teradata, SAP HANA, Firebird, Access, and every warehouse speaking a PostgreSQL or MySQL wire.

The week that earned it

The listing did not come from nowhere; it came at the end of the most productive week this project — and, honestly, I — have had, told in full in Part 2:

• August 25 — I released v0.1.0 on PyPI, crates.io and nuget.org (Part 1: the launch, 46 databases, every number measured).
• August 25–29 — I filed 24 defect reports upstream across 13 other projects, each with a reproduction that needs no adbcBridge in the stack. My unixODBC report drew a maintainer commit the same day.
• August 29–31 — the fixes started landing: a fix PR at Apache Doris, two at QuestDB, one from the psqlodbc maintainer twenty-eight minutes after their reply to me, and CrateDB's fix merged within an hour of a core maintainer picking up my report — shipping in 6.4.4. The live ledger is at adbcbridge.org/upstream/status.json, refreshed hourly.
• August 31 → September 1 — I requested the listing; it was invited, reviewed and merged.

Reading the week as one arc: I proved the bridge could find real bugs in the ecosystem it spans, gave every one back in the most useful form I could, watched maintainers act on them — and then the standard's own documentation put my bridge on the map. That is the give-back loop closing all the way around.

What it actually gets me

Practically, it puts the answer where the question gets asked. A developer reading ADBC's docs with an ODBC-only database no longer has to go searching — the page itself says there is a path, and hands them a snippet to run. The docs now do what docs are for: point the way.

And one full-circle grin I'll allow myself. Three weeks ago, my GPU SQL engine gpudb shipped as an official DuckDB Community Extension — my project living inside DuckDB's ecosystem, installed with INSTALL gpudb FROM community (that story is here). Today, on Apache Arrow's integrations page, adbcBridge stands alongside DuckDB — listed in parallel, as a peer in the same ecosystem. From inside DuckDB to beside it on Arrow's docs, in under a month: that is the full circle. Two projects that started as things I build at my desk are now lines in the official documentation of two of the most-loved tools in data. That is not a growth metric; it is something better — the ecosystem deciding the work is worth pointing at.

And the honest footnotes, because I do those here. First: the listing is documentation, not affiliation. adbcBridge remains my independent, Apache-2.0-licensed implementation of the ADBC standard — it is not an Apache project, and being on the Tools & Integrations page does not make it one; the page describes tools that work alongside ADBC, which is exactly what this is. Second: the entry is live on the development version of the docs today and rolls into the stable current docs with the project's next documentation release — so if you check the current-version page this week and don't see it yet, that is why.

What's next

My roadmap hasn't moved, but this reorders its front: the ADBC Driver Foundry validation suite is now clearly the next milestone that matters — a listing says "this exists"; passing the ecosystem's own validation says "this behaves." After that: the driver bootstrap so a first run can fetch the open-licence ODBC drivers it needs, Windows prefetch and parallel ingest, and eventually the JDBC and OLE DB bridges that let the name earn its plural. My non-goal is also unchanged: where a native ADBC driver exists, use it — it will always be faster. I built adbcBridge for everything else, and as of today, the ADBC docs say so too.