Evaluate @duckdb/node-api to drop classic `duckdb` node-gyp→tar transitive vulns

[ihistand]

Context

type: "export" (shipped in 1.8.0) added the classic duckdb npm package as a @sqlanvil/cli dependency — it's the engine for runner-side Postgres/Supabase exports (cli/api/dbadapters/duckdb_export.ts), externalized in the bundle and installed on the user's machine like pg/mysql2.

Problem

npm i duckdb@^1.4.0 reports 5 high-severity advisories, all in one transitive chain with no fix available:

duckdb → node-gyp → make-fetch-happen → cacache → tar (<=7.5.15)

The advisories are all node-tar path-traversal / symlink issues (e.g. GHSA-34x7-hfp2-rc4v, GHSA-8qq5-rm4j-mr97, GHSA-vmf3-w455-68vh).

Real-world risk is low: node-gyp (and its vulnerable tar) is a build-time tool used only to compile/fetch the native binding during npm install — it is not on the runtime code path. But it shows up in every downstream npm audit, which is noise for users installing @sqlanvil/cli and not a great look.

Proposed action

Evaluate migrating to @duckdb/node-api (the newer official "Neo" Node client), which uses a different distribution/build approach and may avoid the node-gyp→tar chain entirely.

Scope / acceptance criteria

• Confirm @duckdb/node-api resolves cleaner under npm audit (no high-sev transitive chain), on the pinned version.
• Port cli/api/dbadapters/duckdb_export.ts to its API (async/Promise-based; differs from classic duckdb's callback Database/Connection).
• Re-validate the de-risk matrix: Parquet/CSV/JSON round-trip and the postgres + httpfs extensions (the postgres_query + S3/Supabase-Storage path), on macOS arm64 and the Linux Docker build image.
• Confirm it packages through the Bazel yarn_install + externals + :package_tar flow (the classic-duckdb wiring is in packages/@sqlanvil/cli/BUILD externals + root package.json/yarn.lock).
• Green //tests/integration:postgres.spec export cases + //cli/api:dbadapters/duckdb_export*_test.

If @duckdb/node-api doesn't pan out (API gaps, packaging issues, or its own audit problems), document the decision to stay on classic duckdb and note the vulns are build-time-only.

References

• Feature: type: "export" (v1.8.0) — cli/api/dbadapters/duckdb_export.ts
• De-risk notes + packaging: spec/plan in sqlanvil-private/planning/{specs,plans}/2026-06-18-export-action*