← All databases

Vertica into Apache Arrow with ADBC

Vertica 25.3 (OpenText Analytics Database), read and written through adbcBridge — the ADBC driver that loads the database's ODBC driver — verified on Linux and Windows x64. Everything below is the compatibility matrix's record for this row.

Status

Driver and connection string

ODBC driver

Vertica ODBC 25.1 (libverticaodbc.so, native wire)

Wire

native ODBC

adbcBridge

0.1.1 (release)

The connection string the matrix used, as the connection strings reference records it (Databases with their own native protocol and ODBC driver); {drv} is the driver library or its name from odbcinst.ini, and the host, port and credentials are the test server's.

Driver={drv};Server=127.0.0.1;Port=15433;Database=VMart;UID=dbadmin;PWD=;

Python

import adbcbridge

# {drv}: the ODBC driver library (path), or its name from odbcinst.ini
conn = adbcbridge.connect(uri="Driver={drv};Server=127.0.0.1;Port=15433;Database=VMart;UID=dbadmin;PWD=;")
with conn.cursor() as cur:
    cur.execute("SELECT * FROM my_table")
    table = cur.fetch_arrow_table()      # pyarrow.Table

Polars and pandas

import polars as pl, pandas as pd

df = pl.read_database("SELECT * FROM my_table", connection=conn)   # Polars, Arrow-native
pdf = pd.read_sql("SELECT * FROM my_table", conn)                   # pandas 2.2+, ADBC connection

pip install adbcbridge brings the driver library; the Vertica ODBC driver is installed the way its vendor documents, then named in Driver=. Rust, Go, C# and Java use the same connection string through their ADBC driver managers — see the docs.

What the matrix recorded

first-party driver on 5433 — the port speaks the PostgreSQL v3 wire (libpq connects, server_version 14.0) but the PostgreSQL catalogs are absent, so psqlodbc fails at its connect-time pg_type lookup (Relation "pg_type" does not exist) and cannot drive it.

What this stack needed

• Needs no tolerance flags at all (as Cloudberry does not): every workload type is a native Vertica type and the workload round-trips exactly, emoji and microseconds included (i is int64 — Vertica's integer types are all 64-bit aliases).
• f is exact because 1.5 is: the driver passes DOUBLE PRECISION through a 15-significant-digit decimal form in both directions (%1.15e in libverticaodbc.so, SQLDescribeCol size 15), so a bound 3.141592653589793 is stored as 3.14159265358979.
• The entry points VERTICAINI at a vertica.ini of its own for the driver's message catalogue (ErrorMessagesPath; without it every driver diagnostic degrades to [Vertica][DSI] ... Could not open error message files, though the workload still passes) and pins DriverManagerEncoding = UTF-16 — client 25.1 detects unixODBC's 2-byte SQLWCHAR by itself, but UTF-32 there corrupts every wide string in both directions with no error (six U+FFFD) and can abort the process.
• One quirk: its parameter arrays are a native bulk load (COPY ... FROM LOCAL STDIN NATIVE) and beat the one-row-per-execute path 7-8× (17-20k rows/s → 135-139k), so prefer_param_arrays — the flag maodbc already uses.
• Multi-row VALUES is refused on this fixture (Function public.explode("array") does not exist: vcluster create_db --skip-package-install leaves the ComplexTypes package out); with the package installed it parses and runs at ~2.5k rows/s, a column store taking each multi-row VALUES as one row-store insert, so the array path stays ahead either way.
• Server side, vertica/vertica-ce no longer exists (the vertica Docker Hub namespace is empty and the opentext one publishes no CE image), so the entry runs opentext/vertica-k8s and builds the database with vcluster itself (fixtures/setup_vertica.sh); pinned to 25.3 because Vertica 26.1 dropped Community Edition and a 26.x server refuses the licence its own image ships; needs nofile 65536; ingest 151k rows/s (array binding), fetch 948k rows/s