Proposal: Native Db2 LUW dialect and ibm_db driver support

[AWADHAMBIKA]

Summary

I would like to contribute native IBM Db2 LUW support to Drizzle ORM using the ibm_db Node.js driver.

Drizzle is a strong fit for Db2 because SQL generation is implemented in TypeScript dialect classes. A Db2 dialect can therefore generate valid Db2 SQL directly, rather than translating SQL emitted for another database at runtime.

Proposed public API

import { drizzle } from 'drizzle-orm/ibm-db';
import * as ibmdb from 'ibm_db';

const connection = await ibmdb.open(process.env.DB2_CONNECTION_STRING!);
const db = drizzle(connection);

Proposed package boundaries:

drizzle-orm/db2-core: Db2 schema definitions, query builders, dialect, session, and column types
drizzle-orm/ibm-db: ibm_db driver integration and drizzle() entry point

Initial target:
The initial target would be Db2 for Linux, UNIX, and Windows (Db2 LUW) 11.5+.

Db2 for z/OS and Db2 for i would be explicitly out of scope for the initial implementation because they require separate compatibility and operational validation.

Proposed MVP
The first contribution would provide ORM runtime support only:

• TypeScript schema declarations
• Table and column definitions
• CRUD operations
• Joins, predicates, CTEs, and raw SQL
• Bound parameters using Db2 ? placeholders
• Db2 pagination: OFFSET ... ROWS FETCH NEXT ... ROWS ONLY
• Transactions, including rollback behavior
• Common type mappings: integers, BIGINT, DECIMAL, strings, binary, date/time, boolean, and NULL
• Unit tests for generated SQL and integration tests against Db2 LUW

Explicitly deferred
To keep the first contribution reviewable, the following would be separate follow-up work:

• drizzle-kit migration generation and migration application
• Schema introspection
• Drizzle Studio support
• Relational Queries API support, if its generated SQL needs additional Db2-specific work
• Db2 for z/OS and Db2 for i validation
• Advanced Db2 types and features such as XML, DECFLOAT, LOB variants, sequences, MERGE, and procedural SQL

Design constraint

• The Db2 implementation would compile Db2 SQL natively in a dedicated dialect. It would not spoof another database provider or rewrite finalized SQL strings with regex/string transformations.

Questions for maintainers

• Does this package split and public import API align with Drizzle's current direction?
• Which current dialect and Node driver integration would you recommend as the primary implementation reference?
• Would you prefer an initial architecture/proof-of-concept PR, or a complete ORM-runtime MVP PR?
• What CI approach would be acceptable for Db2 LUW integration tests, given the ibm_db native dependency and database availability requirements?

I am planning this work for an upcoming sprint and would like to align on scope and contribution structure before beginning implementation.

[AWADHAMBIKA]

Initial ibm_db validation

Against Db2 LUW using ibm_db 4.0.1:

• Prepared statements and ? parameter binding work.
• BIGINT is returned as a JavaScript string and preserves 64-bit values.
• DECIMAL is returned as a JavaScript number, so precision can be lost.
• BINARY values are returned as Node.js Buffer objects.
• TIMESTAMP values are returned as formatted strings.
• SQL NULL maps to JavaScript null.
• Transaction rollback works as expected.
• Directly inferred Buffer/Date parameters caused CLI HY004; explicit binding metadata is required.
• Exact numeric text can be preserved by binding strings and using Db2-side casts.

The probe is available for reproducing these observations: https://github.com/AWADHAMBIKA/drizzle-db2-probe

[AWADHAMBIKA]

Hi Everyone! Any input here from the maintainers/creator(@AndriiSherman) will be deeply appreciated and will help me to move forward in right direction.