IBM Db2 to Teradata: How to Move Your Data
Move IBM Db2 into Teradata with Airbyte. Why the CDC setup script leaks credentials into logs, and why both ends of this pipeline need an owner's agreement.
Moving IBM Db2 into Teradata joins two systems that have each been running critical work for decades. Db2 holds the transactions and Teradata holds the modelled subject areas, and plenty of organisations need the first inside the second.
This guide covers the managed path with Airbyte. Two things shape the build: the change capture setup has a detail worth catching before it reaches your logs, and both ends of this pipeline belong to somebody who will want to be asked.
IBM Db2 to Teradata at a glance:
Why move data from IBM Db2 to Teradata?
Two situations account for most of these pipelines.
The first is completing a subject area. An organisation modelling customers or products in Teradata usually finds that some of the underlying transactions live in Db2, and reporting across both means bringing one to the other rather than querying two systems.
The second is cost and contention, since analytical queries against a system of record compete with the work that pays for it. If your aim is transformation at scale rather than SQL reporting, IBM Db2 to Databricks asks less modelling of you.
What do you need before you start?
Four things, and two of them need somebody else's agreement:
Certainty about which Db2 this is, and a read-only user. A Db2 for i database needs an additional IBM licence file alongside the JDBC driver. The Db2 source documentation covers the connection details.
A decision about deletes, made with your DBA. Capturing them means trigger-based change capture, with three triggers and a tracking table per replicated table, which is a change to a production system rather than a setting.
A chosen SSL mode and schema name on Teradata. Encryption is off by default and tables land in a schema called airbyte_td unless you say otherwise. The Teradata destination documentation lists the modes.
A short list of tables. Each one is a modelling exercise on arrival and, if you use change capture, a set of triggers at the source, so the selection is the project plan twice over.
If either system restricts traffic by IP, add the Airbyte Cloud IP addresses to the allow lists before you begin.
How do you build an IBM Db2 to Teradata pipeline in Airbyte?
Step 1: Run the CDC setup script where logs are not kept
If you are using trigger-based change capture, run the provisioning script somewhere its output will not be retained, because it prints the connection string including credentials to standard output. In an environment that captures terminal output into a log aggregator, that is a database password sitting in a searchable system nobody intended to put it in. Redirect or suppress it, and rotate afterwards if you are unsure.
Step 2: Configure the Db2 source
Click Sources in the left navigation, then New Source, and select IBM Db2, following adding a source. Supply the host, port, database and credentials. On the community connector an encrypted connection uses a client certificate supplied in the SSL PEM field, from which the connector builds a keystore.
Step 3: Configure the Teradata destination
Click Destinations, then New Destination, and select Teradata, following adding a destination. Supply the host, credentials, logon mechanism and SSL mode, and name the schema. Check numeric precision on money columns, since legacy schemas are often more generous than a default mapping preserves.
Step 4: Create the connection and watch both systems
Click Connections, then New connection, select your streams and a sync mode. Watch the load your syncs place on Db2, where capacity is usually finite and expensive, and keep an eye on the tracking tables if you installed them.
Then start the modelling, because the landing tables are the beginning of the work in this environment rather than the end.
What does the setup script put in your logs?
The connection string, credentials included, written to standard output. That is convenient when somebody is running it by hand and watching the terminal, and considerably less so in an organisation that captures command output into a central log.
The consequence is a database password becoming searchable by anybody with log access, which in a large enterprise is a considerably wider group than the people entitled to that credential. Nothing fails, nothing warns, and the exposure is only discovered if somebody goes looking or an audit finds it.
So plan where you run it. A workstation without log shipping, output redirected to somewhere you control, or a rotation immediately afterwards all work. This is a small detail in the connector's documentation and exactly the kind that matters more in a governed environment than in a startup, which is precisely where both these systems tend to live.
Who has to agree to this pipeline?
More people than usual, because both ends are governed systems with owners. Most pipelines in this catalogue read an API nobody guards closely and write somewhere a data team controls. Here a DBA owns the source, another team owns the destination, and each has a change process that predates your project.
At the source, trigger-based change capture installs three triggers and a tracking table for every table you replicate, inside a dedicated schema. That is a real change to a production system and one a Db2 administrator will reasonably want to review, particularly given that it is explicitly not compatible with IBM's own InfoSphere CDC if they are already running it.
At the destination, the schema name, the SSL mode and the eventual model all touch conventions somebody maintains. So treat this as a negotiation rather than a configuration: bring the trigger design and the target schema to both teams early, and expect the timeline to be set by their review cycles rather than by how quickly the connector can be configured.
Frequently asked questions
Does the setup script really print credentials?
It prints the connection string to standard output, which includes them. Run it where output is not retained, or redirect and rotate afterwards.
Will deleted rows reach Teradata?
Only with trigger-based change capture. Cursor-based reading sees inserts and updates, so removed rows persist in the destination indefinitely.
Can I use this alongside InfoSphere CDC?
No. The trigger-based implementation is explicitly not compatible with it, which is worth establishing with your DBA before designing anything.
Is the Teradata connection encrypted by default?
No. SSL is off by default and two of the six modes permit unencrypted connections, so choose a mode deliberately.
Can I do this without writing code?
The pipeline, yes, though the triggers are database administration. Modelling the landing tables into your subject areas is most of the project.
Get your IBM Db2 data into Teradata
Run the change capture setup script where its output will not be retained, because it prints credentials and a governed environment usually captures everything. Establish which Db2 you are connecting to and whether deletes matter. Then treat this as a negotiation with two owners, bringing the trigger design and the target schema to them early, and set the SSL mode rather than accepting a default that does not encrypt.
Airbyte's connector catalog includes 600+ pre-built connectors, so a system of record can feed analysis without carrying it. For the same source into a cloud warehouse, see IBM Db2 to Amazon Redshift, and for another enterprise database into the same destination, Oracle Database to Teradata.
Integrate with 700+ apps using Airbyte
Move data from 700+ sources into warehouses, lakes, and beyond. Set up pipelines in minutes with pre-built connectors and the Connector Builder.