How to access mainframe data stored in Db2 on z/OS

Mainframes still fill an important niche even as the cloud continues to grow. Storing data in IBM Z and using it as your central data repository is a deliberate choice to harness one of the most powerful, reliable, and secure computing platforms ever built. Global banks, insurance carriers, and healthcare systems rely on IBM Z to process millions of transactions per day.

IBM Db2 on z/OS is the database for IBM Z that handles many of the most critical, high-volume transactional workloads — insurance policies, banking settlements, healthcare records, government payrolls. The challenge is getting data off the mainframe and into the places your analytics team works, whether a data lake or data warehouse, and a dbt-compatible environment for cloud analytics.

[CTA_MODULE]

The two bad options most companies are stuck with

Right now, most organizations are doing one of two things:

A nightly data dump — a scheduled job extracts a snapshot, drops it downstream, and the analytics team works from data that's already a day old. Fine if you enjoy making decisions based on yesterday's news.

A hand-built ETL pipeline — cobbled together by the one person at the company who knows both mainframe systems and data pipeline engineering. These pipelines work great right up until something changes and nobody knows how to fix it.

Neither solution is good (or cheap), which brings us to the part that makes finance teams do a double-take.

Running advanced queries on a mainframe is surprisingly expensive

IBM prices mainframe software based on how hard you make the CPU work.

Every time your data engineering team runs a big SQL query to extract data for analytics, that query is burning CPU cycles that directly affect your software bill. That nightly batch job scanning your biggest tables? It's not just slow — it's costing you real money every time it runs.

Throw in the cost of the specialists required to build and maintain those pipelines, and the "it works, don't touch it" approach starts to look a lot less appealing.

The smarter way: read the log, not the table

Fivetran's Db2 for z/OS connector takes a different approach — change data capture to sidestep most of these problems.

Here's the idea: every change in Db2 (every insert, update, delete) gets written to a transaction log before it touches the actual data. That log is a complete, sequential record of everything that's happened. Instead of running queries against your tables, Fivetran reads the log and captures only what's changed since the last sync.

This means less work on the mainframe, no big table scans, and continuous, up-to-date data instead of a nightly snapshot.

It also helps that Fivetran's connection to Db2 is eligible for zIIP offload. zIIP processors are specialty engines on IBM Z that aren't included in standard software billing. Up to ~60% of Fivetran's connectivity work can shift onto zIIP instead of the general-purpose processors IBM charges you for. For large shops, that's potentially millions in annual savings.

For the mainframe team, the footprint is tiny: two stored procedures, one application environment, and a one-time authority grant. Nothing to babysit or upgrade on a separate schedule.

What it looks like in the real world

A few scenarios where this makes a real difference:

• An insurance company with policy and billing data in Db2 can start running analytics against live data in Databricks without waiting overnight to see what changed.
• A bank can feed transaction data into its cloud warehouse continuously, enabling real-time fraud detection rather than catching fraud that happened yesterday.
• A healthcare organization can keep Db2 as the system of record for patient and claims data while giving its analytics tools access to current information without scheduling heavy extraction jobs during peak hours and spiking the bill.

Getting set up with Fivetran

The number one reaction when describing this to mainframe teams is: "That sounds complicated." It's really not. Just three teams are involved, and none of them have much to do:

z/OS system teams install two stored procedures (we provide the JCL) and create a WLM application environment. Typically about two hours of work, done once. Db2 DBA grants the necessary authority and enables change capture on the relevant tables. Standard operations. Network/security team picks a connectivity path:

• SaaS Direct — Fivetran connects to your Db2 TCP port over TLS. Requires allowing Fivetran's IPs through your firewall.
• Hybrid Deployment — A lightweight agent lives inside your network and makes outbound-only HTTPS calls to Fivetran. Nothing reaches inward to the mainframe. Most teams with strict security requirements pick this one.

After that, Fivetran handles the rest: monitoring, schema changes, incremental syncs. Your data engineering team gets a Db2 z/OS source that behaves exactly like any other Fivetran connector, with the same destination integrations for Snowflake, Databricks, BigQuery, Redshift, and others.

If your organization runs Db2 on z/OS and wants to get that data into your analytics platform, try the connector today.

[CTA_MODULE]

‍