#1939 Apache Cloudberry through ODBC into Apache Arrow (adbcBridge 0.1.0) — is multi-argument unnest a safe bulk-ingest path on Cloudberry? New discussion created by singhpratech adbcBridge is a small Apache-2.0 ADBC driver written in C11 that loads an ODBC driver and exposes it through the Arrow ADBC C ABI: block-cursor reads straight into Arrow record batches, bulk ingest, metadata, partitioned parallel reads. I ran Apache Cloudberry through it as one of 46 databases in a single compatibility workload, and it is one of the few entries that needed no driver quirks and no tolerance flags at all — so I wanted to share the entry here and ask one question at the end. What was verified (Apache Cloudberry 2.1.0-incubating,

woblerr/cloudberry

image; driver psqlodbc 16, PostgreSQL wire): • Linux: PASS • macOS arm64: PASS (amd64 emulated) • Windows x64: PASS (compose service unchanged, 3 GB / shm 1 GB) What the compatibility entry records: an MPP cluster of PostgreSQL 14 segments behind one coordinator, driven by the

postgres

entry's types unchanged (

INTEGER

,

DOUBLE PRECISION

,

VARCHAR

,

BYTEA

,

DATE

,

TIMESTAMP

,

NUMERIC(10,3)

,

BOOLEAN

all behave as on stock PostgreSQL) and, unlike CockroachDB, needing no

PRIMARY KEY

. Since it reports

SQL_DBMS_NAME

"PostgreSQL" behind the same

psqlodbcw.so

, no driver-name quirk could be correct here without also firing on real PostgreSQL; the only place Cloudberry is named in the bridge is a fork test on the

version()

banner. Extra steps cover what the standard workload cannot tell apart from PostgreSQL: a

DISTRIBUTED BY

table whose bulk-ingested rows occupy both segments plus an aggregate merged on the coordinator (

Gather Motion 2:1

, GPORCA), and append-optimized column-oriented storage read from

pg_am

as

ao_column

. Full entry: https://github.com/singhpratech/adbcbridge/blob/main/docs/COMPATIBILITY.md The question. For real PostgreSQL the bridge ingests through a multi-argument

unnest

form —

INSERT INTO t SELECT * FROM unnest($1::bigint[], $2::text[], …)

with one array parameter per column — and it only turns that on when

version()

is a PostgreSQL banner carrying no fork marker, so Cloudberry (banner

PostgreSQL 14.4 (Apache Cloudberry 2.1.0-incubating …)

) keeps the plain multi-row

INSERT

path. Probing Cloudberry directly, the

unnest

form works exactly as on PostgreSQL — from array literals and from bound `bigint[]`/`text[]` parameters, into heap, append-optimized row and append-optimized column tables, across the segments — and server-side it lands 5,000 rows roughly an order of magnitude faster than the multi-row

INSERT

it keeps (~530k vs ~33k rows/s, bare SQL on a shared host). Is relying on multi-argument

unnest

expansion something Cloudberry considers stable across releases, the same way PostgreSQL does — i.e. is it reasonable to let Cloudberry through that gate? If there is a caveat (GPORCA vs the planner, distribution of the unnested rows, anything on the 2.x roadmap), I would rather know before flipping it. Trying it (Python; Rust, Go, Java and C# are on the docs site):

pip install adbcbridge

import adbcbridge with adbcbridge.connect(uri="Driver=psqlodbcw.so;Servername=127.0.0.1;Port=5432;Database=mydb;Username=gpadmin;Password=…;") as conn: with conn.cursor() as cur: cur.execute("SELECT ...") table = cur.fetch_arrow_table() # a pyarrow.Table Links: repository https://github.com/singhpratech/adbcbridge · docs https://adbcbridge.org/docs/ · upstream notes https://github.com/singhpratech/adbcbridge/blob/main/docs/UPSTREAM.md · PyPI https://pypi.org/project/adbcbridge/ It is a 0.1.0. If the entry says something wrong about Cloudberry, or you run a version I didn't, an issue on the repository with the details is the most useful thing you could send. apache/cloudberry