Introducing Fivetran for Db2 for z/OS and Db2 for LUW

IBM Db2 runs the operational core of the world's most demanding enterprises. It comes in three forms: Db2 for z/OS on the mainframe, Db2 for LUW on Linux, AIX, and Windows, and Db2 for i on IBM Power systems. While Fivetran has long supported Db2 for i, we are adding managed-service connectors for Db2 for z/OS and Db2 for LUW — completing support for the IBM Db2 family.

These three forms of Db2 pose distinct challenges. Each environment has its own architecture, economics, and reasons why replicating the data for analytics, dashboarding, reporting, and now AI has historically been so hard. Diving in, we will discuss how Fivetran has built individualized solutions for each Db2 architecture.

[CTA_MODULE]

Db2 for z/OS: Accessing valuable mainframe data

IBM Db2 on z/OS is one of the most reliable transactional databases on the planet. 71% of Fortune 500 companies run IBM Z for their core systems. More than $10 trillion in daily transactions flow through Db2 mainframes globally. Between insurance policies, banking settlements, healthcare records, government payrolls, IBM Z stores and processes the data that runs much of the world’s economy.

However, this valuable data is often difficult for analytics teams to access, requiring custom scripting and replication logic or change data capture. Fivetran abstracts away this DIY work with our managed service connector for IBM Db2 on z/OS. No longer are organizations running nightly batch export or custom ETL pipelines. 

Reading the log, not the table

The key insight behind Fivetran's Db2 for z/OS connector is that the most efficient way to replicate data from Db2 is not to query it at all.

Every committed transaction in Db2 — every INSERT, UPDATE, and DELETE — is recorded in the Db2 transaction log before it is applied to the data pages. Fivetran reads from that log directly, capturing only what has changed since the last sync, rather than scanning source tables to identify new changes.

We do this using IBM's official IFI (Instrumentation Facility Interface), specifically IFCID 306 — the same interface IBM designed for authorized monitoring and replication tools. All log access goes through two small stored procedures installed in an APF-authorized WLM address space on z/OS. The actual log parsing — the computationally heavier work — happens off the mainframe, on Fivetran's platform.

The implications for mainframe economics are significant. Because Fivetran reads the transaction log rather than executing SELECT queries against data pages, the on-mainframe workload is a fraction of what a batch extract requires. And Fivetran connects to Db2 via DRDA over TCP/IP — a connection type eligible for zIIP offload. zIIP processors are specialty engines excluded from MLC billing. Running DRDA connectivity work on zIIP promises considerable MLC savings, especially for larger accounts.

For the mainframe team, this reframes the conversation entirely. Fivetran's Db2 connector doesn't add workload to the mainframe — it moves expensive data extraction work off it. For the DBA, the connector is lightweight by design: two stored procedures, a dedicated WLM application environment, and a one-time grant of MONITOR2 authority. No daemons, no long-running jobs, no proprietary mainframe product to install and upgrade on its own lifecycle.

Db2 for LUW: the same problem, different environment

If your IBM Db2 environment extends to Linux, AIX, or Windows, the pipeline problem looks different on the surface — but the root cause is the same. Data engineering teams trying to feed a modern analytics platform typically fall back on approaches that trade off reliability, freshness, or source database health.

Trigger-based CDC works until a schema change breaks the trigger. Query-based exports scan tables during production hours, adding load at exactly the wrong time. Custom log readers built against Db2's binary log format are complex to get right and expensive to maintain. Legacy on-prem replication tools require dedicated server infrastructure and a team to operate them indefinitely.

Reading the LUW log the right way

IBM provides one sanctioned mechanism for reading Db2 LUW transaction logs: the db2ReadLog API. It is the only programmatic interface to the log. Every log-based CDC tool for Db2 LUW has to use it — what differs is what happens next.

Fivetran installs a lightweight stored procedure on your Db2 server that calls db2ReadLog and returns blocks of log data. Parsing happens off-database, on Fivetran's infrastructure. The LRI (Log Record Identifier) serves as a durable cursor and Fivetran tracks exactly where it left off at the end of every sync and picks up from there on the next one.

The result: no table scans, triggers, or production query path involved during incremental replication. Your Db2 instance carries none of the load from data extraction. Changes are captured continuously and delivered to your destination.

Getting started with Db2 connectors

Db2 for z/OS may require initial coordination between the analytics, mainframe, and network teams — but none of the work is ongoing. The z/OS systems programmer installs two stored procedures via Fivetran-provided JCL (~2 hours, one time) and creates a dedicated WLM application environment. 

The Db2 DBA grants MONITOR2 authority and enables DATA CAPTURE CHANGES on target tables. 

The network team configures one of two paths: SaaS Direct (TLS 1.3, Fivetran IPs allowlisted to reach z/OS) or Hybrid Deployment (outbound-only, no inbound to the mainframe — the most common path for enterprises with restrictive network policies). Requires DB2 Connect Unlimited Edition for System z.

Db2 for LUW requires installing the Fivetran-supplied stored procedure binary on your Db2 server, enabling DATA CAPTURE CHANGES on target tables, and granting the Fivetran user DBADM authorization. Connect via direct connection, SSH tunnel, or PrivateLink. SaaS Direct and Hybrid Deployment are both supported.

After setup on either connector, Fivetran manages everything: connection health, schema drift, re-syncs, incremental updates, pipeline monitoring. Your data engineering team works from the same Fivetran dashboard they use for every other source — same observability, same destination integrations for Databricks, Snowflake, BigQuery, Redshift, and others.

Your entire IBM Db2 footprint on one platform

The analytics team gets continuous, up-to-date data from the system of record — enabling fraud detection, financial reconciliation, operational reporting, and unified customer views that aren't possible with nightly batch exports. The database team gets a connector architecture that protects the source system, reduces on-database workload, and requires no proprietary replication product to operate. And leadership gets a data platform initiative that can actually deliver because the replication pipeline from IBM Db2 is now simple and easy. 

[Get started with Db2 for z/OS →]

‍[Get started with Db2 for LUW →]

[CTA_MODULE]

‍