Implement an ADBC backend

[hadley]

There are two ways of installing adbc drivers:

• Wrapped in R packages, e.g. pak::pak("adbcsqlite")
• Using dbc, e.g. dbc install sqlite

Then you can generate an DBI compatible connection with adbi:

con1 <- DBI::dbConnect(adbi::adbi("adbcsqlite"), uri = ":memory:")
con2 <- DBI::dbConnect(adbi::adbi(adbcdrivermanager::adbc_driver("sqlite")), uri = ":memory:")

It'll be easiest to test with adbcsqlite since that keeps everything in R package space, even though we probably expect most people will use dbc in practice.

@ianmcook supplied this translation of driver names to SQL dialects that would be a good place:

bigquery: bigquery
duckdb: duckdb
dremio: flightsql
gizmosql: flightsql
starrocks: flightsql
mssql: mssql
mariadb: mysql
mysql: mysql
tidb: mysql
vitess: mysql
cedardb: postgresql
citus: postgresql
cockroachdb: postgresql
cratedb: postgresql
neon: postgresql
paradedb: postgresql
postgresql: postgresql
timescaledb: postgresql
yellowbrick: postgresql
yugabytedb: postgresql
redshift: redshift
snowflake: snowflake
sqlite: sqlite
trino: trino

We're currently missing some way to reliably extract the driver name from the connection. @eitsupi suggested con@database$driver$name, but that doesn't work for me.

[eitsupi]

Sorry, it looks like we need to check
ADBC_INFO_VENDOR_NAME (code 0).
This varies depending on the destination, so you can expect the same driver to return different values ​​when connected to different destinations.
https://github.com/apache/arrow-adbc/blob/b51a5d186bdde77af7d1abf6f9c06f2935fd1d26/c/driver/postgresql/database.h#L67-L73

con1 <- DBI::dbConnect(adbi::adbi("adbcsqlite"), uri = ":memory:")
con2 <- DBI::dbConnect(adbi::adbi(adbcdrivermanager::adbc_driver("sqlite")), uri = ":memory:")

con1@connection |>
  adbcdrivermanager::adbc_connection_get_info() |>
  tibble::as_tibble()
#> # A tibble: 5 × 2
#>   info_name info_value$string_value $bool_value $int64_value $int32_bitmask
#>       <dbl> <chr>                   <lgl>              <dbl>          <int>
#> 1         0 SQLite                  NA                    NA             NA
#> 2         1 3.45.1                  NA                    NA             NA
#> 3       100 ADBC SQLite Driver      NA                    NA             NA
#> 4       101 (unknown)               NA                    NA             NA
#> 5       102 0.7.0                   NA                    NA             NA
#> # ℹ 2 more variables: info_value$string_list <list<chr>>,
#> #   $int32_to_int32_list_map <list<df[,2]>>

con2@connection |>
  adbcdrivermanager::adbc_connection_get_info() |>
  tibble::as_tibble()
#> # A tibble: 6 × 2
#>   info_name info_value$string_value $bool_value $int64_value $int32_bitmask
#>       <dbl> <chr>                   <lgl>              <dbl>          <int>
#> 1         0 SQLite                  NA                    NA             NA
#> 2         1 3.50.4                  NA                    NA             NA
#> 3       100 ADBC SQLite Driver      NA                    NA             NA
#> 4       101 (unknown)               NA                    NA             NA
#> 5       102 0.7.0                   NA                    NA             NA
#> 6       103 <NA>                    NA               1001000             NA
#> # ℹ 2 more variables: info_value$string_list <list<chr>>,
#> #   $int32_to_int32_list_map <list<df[,2]>>

^{Created on 2026-01-21 with reprex v2.1.1}

[ianmcook]

@hadley here's the "official" source for the mapping I shared: https://github.com/adbc-drivers/name-mappings

For clarity, this is a mapping of system names to ADBC driver names (where "system" means: a database, data warehouse, cloud data platform, query engine, or similar). This is not a mapping of dialects to drivers per se.

The idea behind this is: if the user specifies only which system they want to connect to, then you can use that to infer which ADBC driver to use (using this mapping) and also to infer which dialect of SQL to use.