ADBC drivers: lessen van Columnar over zero-copy problemen

Samenvatting

ADBC-drivers maken zero-copy mogelijk, maar Columnar toont waarom formaten en types dat in productie bemoeilijken.

ADBC-drivers en zero-copy in productie

Columnar besprak tijdens dbt Summit 2026 een jaar aan ervaringen met ADBC-drivers voor productieomgevingen. ADBC staat voor Arrow Database Connectivity en biedt één leveranciersneutrale, Apache-gelicentieerde API voor verschillende databases. Drivers leveren gegevens aan in Apache Arrows kolomvormige geheugenformaat, in plaats van via rijgerichte protocollen zoals ODBC en JDBC.

dbt v2 gebruikt ADBC als communicatielaag voor adapters. Ook Power BI, Apache Airflow en dltHub hebben ADBC geadopteerd. Snowflake en Databricks leveren gegevens al native als Arrow, waardoor serialisatie kan worden overgeslagen zodra de gegevens in Arrow staan.

Waarom ADBC belangrijk is

De belofte van zero-copy stopt zodra een database geen Arrow teruggeeft. Postgres, Trino en SQL Server leveren volgens Columnar nog JSON of andere rijgerichte formaten; de driver moet die gegevens dan zelf omzetten. Daarmee verschuift de complexiteit naar de verbindingslaag.

Vooral types zorgen voor problemen. SQL kent geen uniforme maximale precisie voor numerieke waarden: SQL Server gebruikt maximaal 38 cijfers, ClickHouse 76, MySQL en MariaDB 65, terwijl Postgres meer dan 1.000 expliciete cijfers toestaat. BigQuery negeert gedeclareerde precisie en retourneert altijd decimal128(38,9).

Ook tekst en tijdstempels gedragen zich niet uniform. Oracle behandelt lege strings als null, SQL Server gebruikt UTF-16 en ClickHouse heeft geen afzonderlijk binary-type. Snowflake bewaart een tijdzone-offset per rij, waarvoor Apache Arrow een nieuw extension-type toevoegde.

Concrete takeaway voor ADBC-integraties

Test ADBC-drivers niet alleen op verbinding en snelheid, maar ook op decimalen, lege strings, encodering en tijdstempels per databasesysteem. Arrow-output betekent niet automatisch dat de hele route zero-copy blijft.