adbcBridge has a page in QuestDB's documentation
QuestDB's documentation now has an adbcBridge page: Integrations › Other Tools › adbcBridge, with a bullet on the integrations overview. It was written here, sent as questdb/documentation#564, reviewed by QuestDB and merged on 2026-11-06.
What the page covers
It is the short form of this site's QuestDB docs, in QuestDB's own voice and structure:
- The native driver first.
adbc_driver_questdbspeaks QWP, QuestDB's columnar wire protocol, through QuestDB's official C client. The page gives the build, the connection options (uri,username,password,adbc.questdb.token), a Python example throughadbc_driver_manager.dbapiand a TypeScript one through@apache-arrow/adbc-driver-manager, bulk ingest from an Arrow table, and what comes back: every QuestDB type as its Arrow counterpart, transactions reported as not implemented, and the one server-side limit that still stands, aSELECTof aDECIMALcolumn with precision 9 or less, which questdb/questdb#8111 lifts. - The ODBC route for QuestDB 9 and older. One section: install from PyPI, crates.io, NuGet or
Go, connect through psqlodbc with
autocommit=True, and why that flag matters there (QuestDB has noSAVEPOINT, which psqlodbc sends inside a transaction).
Every snippet was run against QuestDB 10.1.0 before the page went up: the QWP query returns its
rows as timestamp[us] and float64, the ODBC query its 226 rows through psqlodbc.
How it came about
The pull request opened on 2026-09-24, when the page described the ODBC route alone, because that
was what existed. A month later QuestDB answered the ADBC request on its roadmap with "over QWP,
please" (the QWP note), and adbc_driver_questdb shipped in 0.1.4
on 2026-10-28. On 2026-11-03 the reviewer asked the two right questions: does the page need a
rewrite now that the driver has changed, and should Python and Rust be the first install options
when QuestDB's own clients cover those languages natively? The rewrite went up the same day: the
native driver leads, the install block starts with the driver build and an ADBC driver manager,
QuestDB's own Python and Rust clients are named as the direct route, and the ODBC bridge is the
section for older servers. QuestDB merged it three days later, fixing one internal link on the way.
QuestDB's own announcement
The same afternoon QuestDB posted the page on its LinkedIn page, in its own words:
New entry in the #QuestDB third-party integrations list: adbcBridge, which provides ADBC drivers for QuestDB. Our own clients that hand you Arrow over QWP are C and C++, Rust, Python and Ruby. If you work in C#, Java, Go or TypeScript, or in a tool that takes any ADBC driver, this is how you get there. It comes in two flavours. On QuestDB 10 or newer, a native driver that speaks QWP and gives you Arrow batches for both reads and bulk ingest. On QuestDB 9 or older, an ODBC bridge over PGWire, which is also the one to pick when a single driver has to serve several databases.
That is the positioning exactly as intended: QuestDB's own clients where they exist, adbcBridge for the languages and tools they do not cover, and the ODBC bridge when one driver has to serve many databases.
What this means for the matrix
Nothing changes in the measurements. The QuestDB row stays the ODBC path as measured, the QWP note keeps the numbers for the native driver (2M rows in 0.125 s against 1.47 s over psqlodbc), and the upstream record gains a row for the documentation itself, next to the omniload backend: a contribution rather than a report. If you reach QuestDB through ADBC, QuestDB's page is now the place to start, and this site is where the detail lives.