> ## Documentation Index > Fetch the complete documentation index at: https://docs.flowx.ai/llms.txt > Use this file to discover all available pages before exploring further. # Db2 Database > Connect to IBM Db2 databases as a data source in FlowX workflows and run SQL queries against them. export const release_0 = "5.12" SaaS · {release_0} **Available on SaaS with FlowX.AI {release_0}.** This feature is live on managed (SaaS) deployments now. Self-hosted deployments will receive it with the next LTS release family. ## Overview Db2 is a relational data source type that lets you connect FlowX workflows to **IBM Db2 databases that your organization manages independently**. You configure a connection, save named SQL queries against the schema, and call those queries from workflows. Pick the Db2 product, then fill in a connection shaped for it Monaco editor with SQL syntax highlighting, schema-aware autocomplete, and a side panel that lists tables, columns, primary keys, and foreign keys Run any saved query with sample parameters and inspect the response: table view for SELECT, affected-row count for INSERT / UPDATE / DELETE Reference Db2 queries from the Database Operation node alongside other data sources *** ## Supported Db2 products Db2 ships as separate products that differ in JDBC driver, URL form and listener port, so a connection begins by naming which one it targets. | Db2 Product | Use for | Default port | | --------------------- | -------------------------------------------------------------- | ---------------------------- | | **Db2 for i (IBM i)** | Db2 on IBM i, formerly AS/400 and iSeries. This is the default | `8471`, or `9471` with SSL | | **Db2 LUW** | Db2 on Linux, UNIX and Windows | `50000`, or `50001` with SSL | **Db2 for z/OS** appears in the **Db2 Product** list but is not implemented in this release. Selecting it and testing the connection fails with an explicit error naming the product, rather than silently connecting through another driver. *** ## Prerequisites * A Db2 instance accessible from your FlowX deployment, running one of the supported products above * A database user with the privileges your queries require, plus read access to the catalog views used for schema discovery * Network connectivity between the `nosql-db-runner` service and the Db2 instance * For SSL connections: appropriate certificates configured on the Db2 instance and trusted by the FlowX deployment * For Db2 for i, a job or user profile whose CCSID lets character data come back as text. See [character data returned as binary](#character-data-returned-as-binary) *** ## Creating a Db2 data source Navigate to **Integration Designer** → **Data Sources** in your project. Click the **+** button to open the **Add Data Source** dialog. In the **Databases** category, select **Db2 Database**. Set **Db2 Product**. The rest of the form follows from this choice, and the **Port** field is prefilled with that product's standard port. Db2 for i is preselected. Fill in the connection fields: | Field | Description | | --------------- | -------------------------------------------------------------------------- | | **Host** | Db2 server hostname or IP | | **Port** | Listener port. Prefilled from the product and the SSL toggle, and editable | | **Library** | Optional. The default library or schema for queries and discovery | | **SSL Enabled** | Toggle SSL on or off for the connection | | **Username** | Database username | | **Password** | Database password | Each field accepts configuration parameters for environment-specific values. On Db2 for i, set **Naming** and, if you use system naming, **Library List**. See [Naming and the library list](#naming-and-the-library-list). Click **Test Connection and Rescan** to verify connectivity and refresh the schema cache. The data source is created even if the connection test fails, so you can save partial configuration and resolve connectivity later. Return to the **Settings** tab and click **Test Connection and Rescan** once the issue is fixed. Click **Save** to create the data source. Db2 does not assume a port. The prefilled value is the product's standard listener port, offered so you can see and change it, and a port is required for every vendor. *** ## Naming and the library list On Db2 for i, **Naming** decides how a library is addressed in your SQL: | Naming | Meaning | | ------------------------------------------------------- | ---------------------------------------------------------------------------------------------- | | **SQL, dot notation (MYLIB.MYTABLE)** | Qualify a table with its library, using a dot | | **System, resolved through the library list (MYTABLE)** | Refer to a table by name alone, resolved through the library list of the job running the query | SQL naming is the default. When you choose system naming, set **Library List** to the libraries the job should search. *** ## Character data returned as binary If character columns come back as unreadable bytes, the Db2 for i job is most likely running without a translation CCSID. The durable fix is on the server: change the job or user profile CCSID so Db2 returns character data as text. As a client-side workaround, turn on **Translate binary data as character data**. This switch also decodes genuinely binary columns as text, which can corrupt their contents. Prefer fixing the CCSID on the server, and use the switch only where you know the affected columns hold text. *** ## Queries Db2 queries are written and tested the same way as for other relational data sources. See [Oracle Database](./oracle-database#queries) for the SQL editor, testing, and stored-procedure behavior, which are shared across relational data source types. *** ## Using in workflows Db2 queries are called from the existing **Database Operation** node in workflows. On the workflow canvas, drag a **Database Operation** node onto the workspace. In the node configuration panel, pick the Db2 data source. The query picker then lists only the queries saved on that data source. Map workflow inputs to the query's bind parameters. Map the response (rows or `affectedRows`) to a workflow variable. *** ## Deployment No new microservices are required. Db2 queries run inside the existing **`nosql-db-runner`** service, which bundles the Db2 JDBC driver. Each Db2 data source uses its own connection pool. Ensure the `nosql-db-runner` service has network access to your Db2 instance. If Db2 is behind a firewall, configure the appropriate network rules. Global pool and query defaults are shared with the other relational data source types. See [Oracle Database](./oracle-database#configuration-defaults) for the `nosql-db-runner` environment variables that set them. ### Per-data-source advanced settings Each Db2 data source can override the global defaults from its **Advanced settings** panel, grouped into **Pool size**, **Pool lifecycle**, **Liveness**, **Performance**, and **Session**. Fields left empty inherit the global value: | Setting | Description | | ------------------------------ | --------------------------------------------------------------------------------------- | | **Min Pool Size** | Minimum number of connections kept open in the pool | | **Max Pool Size** | Maximum number of connections in the pool | | **Connection Timeout (ms)** | Maximum time to wait for a connection from the pool | | **Unused Timeout (ms)** | Time an idle connection may sit in the pool before being retired | | **Aged Timeout (ms)** | Maximum lifetime of a pooled connection | | **Keep Alive** | Keep-alive probing for pooled connections | | **Maintenance Frequency (ms)** | Interval between pool housekeeping runs. Editable only when **Keep Alive** is turned on | | **Validate Connection String** | Query used to validate connections before use | | **Response Timeout (ms)** | Per-query execution timeout for this data source | | **Transaction Isolation** | Isolation level for the JDBC session. See below | | **Read-Only Connection** | Whether connections open read-only | **Prepared Statement Cache Size**, offered for some other relational data source types, does not appear for Db2 for i, which has no equivalent driver knob. It is available for Db2 LUW. ### Read-only connections on Db2 for i On **Db2 for i**, connections open **read-only by default**. Reading from a live system is the common case, and a read-only connection keeps queries from consuming interactive capacity on writes that were not asked for. Turn **Read-Only Connection** off on the data source if your queries need to write. This default applies to Db2 for i only. Other relational data source types, Db2 LUW included, open read-write unless you say otherwise. ### Transaction isolation **Transaction Isolation** sets the isolation level for the JDBC session: | Option | | | --------------------------- | ----------- | | **None, no commit control** | The default | | **Read Uncommitted** | | | **Read Committed** | | | **Repeatable Read** | | | **Serializable** | | The default is **None** because many Db2 for i tables are not journaled, and a table without a journal cannot take part in a transaction. Asking for any other level would make every query against such a table fail. The isolation level is validated when you save the data source, not when a query first runs, so an unsupported combination surfaces at configuration time. *** ## Related resources Connect to independently managed Oracle databases Connect to independently managed PostgreSQL databases Overview of all data source types and workflow building Deployment configuration for the database runner service ## Related topics - [FlowX.AI 5.12.0 Release Notes](/release-notes/v5.x/v5.12.0-september-2026/v5.12.0-september-2026.md) - [Integration Designer](/5.9/docs/platform-deep-dive/integrations/integration-designer.md) - [Oracle Database](/5.9/docs/platform-deep-dive/integrations/oracle-database.md) - [PostgreSQL Database](/5.9/docs/platform-deep-dive/integrations/postgresql-database.md) - [FlowX Database](/5.9/docs/platform-deep-dive/integrations/flowx-database.md)