Skip to main content

DB2 to Snowflake: Incremental Sync via Iceberg

Moving IBM DB2 LUW (Linux, UNIX and Windows) data to Snowflake usually means a licensed replication product or a nightly EXPORT and COPY INTO. This guide does it with OLake Go. It reads the DB2 tables with a read-only user, writes them once as Apache Iceberg tables into a catalog Snowflake reads, and keeps them fresh on a cursor column.

With Snowflake's own Horizon catalog, the default on this page, the files sit on Snowflake-managed storage. With AWS Glue, the files sit in your S3 bucket and Snowflake reads them through a catalog integration.

By Shubham Satish BaldavaUpdated October 30, 2026

Key takeaways

  • OLake Go replicates DB2 LUW into Snowflake as Iceberg tables: a full historical snapshot first, then incremental syncs on a cursor column such as UPDATED_AT. No SQL Replication setup, replication license or Kafka sits in between.
  • Through the Horizon catalog the tables land as Snowflake-managed Iceberg tables. You query them in Snowsight right away, with no CREATE ICEBERG TABLE, no external volume and no refresh.
  • The same tables, written once by OLake Go, are also queryable from DuckDB and Spark through the same catalog. In the run on this page all three engines returned identical rows.

The short answer. To replicate DB2 to Snowflake, run OLake Go with a read-only DB2 user as the source and the Snowflake Horizon catalog as the Iceberg destination. The first sync copies each table in full (the historical snapshot); every later sync fetches the rows whose cursor column moved and upserts them. Snowflake, DuckDB and Spark then query the same Iceberg tables, with no second copy.

How DB2 data reaches Snowflake here​

The first sync reads the row and page counts DB2 keeps for each table, splits the table into chunks, and reads the chunks in parallel. It writes Parquet data files and records the highest cursor value it saw. Every later sync selects rows above that value, writes them as new data files, and adds a delete file that retires the old version of each updated row.

Each sync ends with one commit to Horizon. OLake Go asks Horizon for short-lived storage credentials, uploads the data and delete files, then posts the new snapshot. Snowflake sees it the moment the commit lands; DuckDB and Spark see it on their next catalog load.

The cursor is the whole contract. A row that changes without its UPDATED_AT moving is never picked up, and a deleted row stays in the Iceberg table. Set the column in every write path, and soft-delete if deletes matter.

What you need​

  • DB2 LUW 11.5.3 or later, with a read-only user, statistics on each table and a cursor column. The tables on this page ran on DB2 12.1.5 Community Edition in Docker.
  • An amd64 host for the DB2 connector. IBM's driver has no Linux arm64 build. On an Apple silicon Mac, turn on Rosetta in Docker Desktop.
  • A Snowflake account where you can run the one-time setup as ACCOUNTADMIN. Snowflake-managed storage means no cloud bucket or IAM role on your side.
  • OLake UI from the Docker Compose install. The run on this page used OLake Go v1.1.0.

Step 1: Prepare DB2 for incremental sync​

Most readers point OLake Go at tables they already have. To follow along with the exact data from this page, create these two tables first:

The two sample tables used on this page
Sample schema, in schema DB2INST1 of database SHOP
CREATE TABLE customers (
  id INT GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY,
  name VARCHAR(100), email VARCHAR(200), city VARCHAR(100), tier VARCHAR(20),
  created_at TIMESTAMP DEFAULT CURRENT TIMESTAMP,
  updated_at TIMESTAMP DEFAULT CURRENT TIMESTAMP);

CREATE TABLE orders (
  id INT GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY,
  customer_id INT REFERENCES customers(id),
  product VARCHAR(100), amount DECIMAL(10,2), status VARCHAR(20),
  created_at TIMESTAMP DEFAULT CURRENT TIMESTAMP,
  updated_at TIMESTAMP DEFAULT CURRENT TIMESTAMP);

-- Then insert whatever you like. This page started with 8 customers and 40 orders.

OLake Go reads DB2 LUW (Linux, UNIX and Windows) tables through IBM's Data Server driver: a parallel full snapshot first, then incremental syncs that fetch only rows whose cursor column moved past the last value seen. The DB2 connector has no log-based change data capture (CDC), so four things must be in place before the first sync.

SettingValueWhy it matters
A read-only userCONNECT on the database plus SELECT on each tableThe snapshot and every incremental sync read the tables directly. DB2 authenticates users against the operating system or LDAP, so the account exists there first and is then granted in the database.
Table statisticsRUNSTATS on every table you syncOLake Go reads the row count and page count from SYSCAT.TABLES to split the snapshot into chunks. A table that has never had statistics collected stops the sync with stats not populated. Stale statistics are fine.
A cursor columna column that grows with every change, such as UPDATED_ATIncremental syncs select WHERE cursor > last value. Rows updated without touching the cursor are not picked up.
A primary keyon every tableOLake Go uses it to upsert changed rows into the Iceberg table. Without one, changed rows are appended.
On the DB2 database, as the instance owner or a DBADM user
-- 1. A user for OLake Go. Create the operating system account first,
--    for example: useradd -M olake && passwd olake
GRANT CONNECT ON DATABASE TO USER olake;

-- 2. Read access to the tables you sync
GRANT SELECT ON TABLE db2inst1.customers TO USER olake;
GRANT SELECT ON TABLE db2inst1.orders TO USER olake;

-- 3. Statistics on every table you sync
CALL SYSPROC.ADMIN_CMD('RUNSTATS ON TABLE db2inst1.customers AND INDEXES ALL');
CALL SYSPROC.ADMIN_CMD('RUNSTATS ON TABLE db2inst1.orders AND INDEXES ALL');

-- 4. A cursor column that your application always sets, for example
--    updated_at TIMESTAMP DEFAULT CURRENT TIMESTAMP, updated on every change

Check the result before moving on. A CARD of -1 means statistics were never collected:

sql
SELECT tabname, card, npages FROM syscat.tables WHERE tabschema = 'DB2INST1';

Version, driver and SSL details are on the DB2 connector page.

The DB2 connector image is built for amd64 only

IBM's Data Server driver has no Linux arm64 build, so olakego/source-db2 runs on amd64 hosts. On an Apple silicon Mac, turn on Rosetta in Docker Desktop and pull the image with --platform linux/amd64.

Deletes do not replicate in incremental mode

A deleted row has no cursor value to read, so it stays in the Iceberg table. If deletes matter, soft-delete in DB2 (a deleted_at column that also bumps updated_at) or schedule an occasional full refresh.

Step 2: Set up the catalog in Snowflake​

Snowflake reads Iceberg tables from two kinds of catalog. Horizon is Snowflake's own: OLake Go writes straight into it, the tables are Snowflake-managed, and they appear in Snowsight the moment a sync commits.

AWS Glue is a catalog outside Snowflake, so the files stay in your S3 bucket. Snowflake reaches them through a catalog integration: a read-only link to that external catalog, refreshed after each sync.

Horizon is the default on this page. Glue is the right pick when Athena, Redshift or Spark on Amazon Elastic MapReduce (EMR) will read the same tables.

CatalogOLake Go writesSnowflake readsVerified on this page
AWS GlueYesYes: catalog integration (read-only)Documented, not yet run by us
Snowflake HorizonYesYes: native: tables are Snowflake-managed Iceberg tablesYes, end to end

Snowflake Horizon is the catalog built into every Snowflake account. OLake Go talks to it through the Iceberg REST endpoint at https://<account_identifier>.snowflakecomputing.com/polaris/api/catalog, and the tables it creates are Snowflake-managed Iceberg tables. Writing through this endpoint needs OLake Go 0.11.0 or later.

Run the following once in a Snowsight worksheet as ACCOUNTADMIN. It creates a database for the tables, a role OLake Go writes as, a service user that holds the token, and the authentication policy the token needs.

Snowflake, once per account
USE ROLE ACCOUNTADMIN;

-- A small warehouse for your own queries, and the database OLake Go writes into.
CREATE WAREHOUSE IF NOT EXISTS OLAKE_WH WAREHOUSE_SIZE = XSMALL AUTO_SUSPEND = 60 AUTO_RESUME = TRUE;
CREATE DATABASE IF NOT EXISTS OLAKE_DEMO;
ALTER DATABASE OLAKE_DEMO SET CATALOG = 'SNOWFLAKE';
ALTER DATABASE OLAKE_DEMO SET EXTERNAL_VOLUME = 'SNOWFLAKE_MANAGED';

-- The role OLake Go uses. It needs to create schemas; tables are created inside them.
CREATE ROLE IF NOT EXISTS OLAKE_ROLE;
GRANT USAGE, CREATE SCHEMA ON DATABASE OLAKE_DEMO TO ROLE OLAKE_ROLE;
GRANT USAGE ON WAREHOUSE OLAKE_WH TO ROLE OLAKE_ROLE;
GRANT ROLE OLAKE_ROLE TO ROLE SYSADMIN;

-- A service user for OLake Go. It holds the programmatic access token.
CREATE USER IF NOT EXISTS OLAKE_SVC TYPE = SERVICE DEFAULT_ROLE = OLAKE_ROLE;
GRANT ROLE OLAKE_ROLE TO USER OLAKE_SVC;

-- Snowflake issues a token to a service user only under a network policy, unless an
-- authentication policy waives that. This one waives it. Any schema can hold the policy.
USE SCHEMA OLAKE_DEMO.PUBLIC;
CREATE AUTHENTICATION POLICY IF NOT EXISTS olake_pat_policy
  PAT_POLICY = (NETWORK_POLICY_EVALUATION = ENFORCED_NOT_REQUIRED);
ALTER USER OLAKE_SVC SET AUTHENTICATION POLICY olake_pat_policy;

-- The two values OLake Go asks for.
SELECT CURRENT_ORGANIZATION_NAME() || '-' || CURRENT_ACCOUNT_NAME() AS account_identifier,
       CURRENT_REGION() AS region;

-- The token. Snowflake shows the secret once; copy it straight into OLake Go.
ALTER USER OLAKE_SVC ADD PROGRAMMATIC ACCESS TOKEN OLAKE_PAT
  ROLE_RESTRICTION = 'OLAKE_ROLE' DAYS_TO_EXPIRY = 30;

What each block is for:

  • CATALOG = 'SNOWFLAKE' and EXTERNAL_VOLUME = 'SNOWFLAKE_MANAGED' on the database make every table OLake Go creates a Snowflake-managed Iceberg table on Snowflake's own storage. No S3 bucket, IAM role or external volume on your side. To keep the files in your own bucket, create an external volume and name it here instead.
  • The authentication policy is the step people miss. Without it, the ADD PROGRAMMATIC ACCESS TOKEN line fails with Network Policy is required when creating a programmatic access token for user OLAKE_SVC. In production, attach a network policy that allows OLake Go's egress IP instead of waiving the check.
  • ROLE_RESTRICTION pins the token to OLAKE_ROLE, so a leaked token cannot act as ACCOUNTADMIN. Tokens expire after DAYS_TO_EXPIRY (15 by default, 365 at most). Rotate it before then or the sync fails with an authentication error.

You can check the token outside OLake Go by exchanging it for a session token, the same call OLake Go makes on every sync:

Token check
curl -s -X POST "https://<account_identifier>.snowflakecomputing.com/polaris/api/catalog/v1/oauth/tokens" \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  --data-urlencode grant_type=client_credentials \
  --data-urlencode scope=session:role:OLAKE_ROLE \
  --data-urlencode client_secret=<your PAT>

A good token returns a JSON object with an access_token. The other authentication methods (key-pair JWT, External OAuth, workload identity federation) are on the Horizon catalog page.

Step 3: Connect DB2 to OLake Go​

  1. In the OLake UI, open Sources and click Create Source. Pick DB2 LUW as the connector, give the source a name and keep the OLake Go version on the latest release.
  2. Fill in the host, the port (50000 by default), the database name, and the username and password from step 1. The Enable CDC switch stays off: DB2 runs in incremental mode only.
  3. Click Set up source. OLake Go tests the connection and saves the source.

Here is the source form from the run on this page. DB2 ran in another container, so the host is host.docker.internal, with database shop on port 50000. The change data capture (CDC) switch is greyed out with Not supported, which is expected for DB2.

OLake UI Edit source form for DB2 LUW on OLake Go v1.1.0 with CDC marked not supported, host host.docker.internal, port 50000, database shop and user db2inst1
The DB2 source in OLake UI: database shop on port 50000, with CDC not supported for this connector.

The full field reference, including SSL and SSH tunnels, is on the DB2 connector page.

Step 4: Configure the Iceberg destination​

  1. Open Destinations and click Create Destination.
  2. Pick Apache Iceberg as the connector and Horizon as the catalog type.
  3. Choose Programmatic Access Token (PAT) as the authentication type and fill in the fields below.
  4. Click Create. OLake Go calls the Horizon endpoint, exchanges the token and saves the destination.
OLake UI destination form for the Snowflake Horizon catalog with the PAT authentication fields

Horizon Configuration Parameters

ParameterSample ValueDescription
Authentication Type
required		Programmatic Access Token (PAT)Authentication method OLake Go uses for Horizon Catalog REST API requests. Set to match your workspace's authentication configuration.
Horizon Iceberg REST Catalog URI
required		https://<account_identifier>.snowflakecomputing.com/polaris/api/catalogSnowflake Horizon Catalog REST API endpoint.
Snowflake Database
required		SNOWThe name of the database in Snowflake.
Session Role Scope
required		session:role:<HORIZON_ROLE>Informs Snowflake which role to use for this Horizon Catalog REST session, which controls privileges for catalog and table operations. Space-separated if providing more than one.
Programmatic Access Token
required		ver:1-hint:...Snowflake programmatic access token (PAT).
Cloud Storage Region
required		AWS_AP_SOUTH_1Snowflake's account region used to route requests to the correct storage endpoint. Run SELECT CURRENT_REGION(); to know the region
Catalog NamehorizonName of the Iceberg catalog OLake Go registers tables under. Defaults to olake_iceberg if left empty.
Enable Arrow WritesfalseWrites data and delete files using Apache Arrow based writer and registers them in Iceberg.
Catalog Name Supported for v0.3.5 and above
For the catalog name, OLake Go only supports lowercase letters and underscores. Spaces and special characters are not supported.

Step 5: Create the job and run the first sync​

  1. Open Jobs and click Create Job. Give it a name and a schedule. Every Day at a fixed hour, or a cron expression, both work; the schedule is how often the change stream is drained, not how often a full copy runs.
  2. Select the source and the destination you created.
  3. Under Advanced Settings, set Target Query Engines to Snowflake, plus DuckDB and Apache Spark if they will read the tables too. OLake Go then resolves an Iceberg delete format every one of those engines can read, so you never pick one by hand.
  4. Click Next. OLake Go discovers the tables and opens the Streams page.
  5. Tick the tables to replicate. For each one, set the sync mode to Full Refresh + Incremental with UPDATED_AT as the cursor column and the ingestion mode to Upsert. Leave the Upsert Type as OLake Go resolved it (Positional Deletes in the run on this page).
  6. Click Create Job, then open the job's menu and choose Sync Now for the first run.

Three target query engines were set on this job, and OLake Go resolved the delete format all three read. Because the DB2 connector has no CDC mode, each stream runs as Full Refresh + Incremental with UPDATED_AT as the cursor. DB2 reports unquoted names in upper case, so the streams and columns appear that way.

OLake UI Streams Selection page with the DB2INST1 schema, CUSTOMERS and ORDERS selected, sync mode Full Refresh + Incremental, CDC options disabled, cursor field UPDATED_AT, ingestion mode Upsert and upsert type Positional Deletes
Each stream: Full Refresh + Incremental on UPDATED_AT, Upsert, and the upsert type OLake Go resolved (Positional Deletes in this run).
OLake UI Job Logs and History for db2_to_snowflake showing two completed syncs, the first in 28 seconds and the second in 22 seconds
Job history: the 28 s historical snapshot, then the 22 s incremental sync.

On this page the first run copied 8 customers and 40 orders (48 records, 2.38 KB) and finished in 28 seconds, container start included. OLake Go names the destination schema after the job, the database and the DB2 schema, lower-cased: db2_to_snowflake on SHOP.DB2INST1 produced db2_to_snowflake_shop_db2inst1. The Iceberg DB field at the top of the Streams page changes it before the first sync.

Step 6: Query the tables in Snowflake​

There is no registration step. The schema and tables OLake Go committed through Horizon are already Snowflake-managed Iceberg tables in the database you configured. One thing to know before the first query: OLake Go creates them with quoted, lowercase names, so Snowflake needs the double quotes.

Snowsight
-- What OLake Go created (schema = <job name>_<source database>[_<source schema>])
SHOW ICEBERG TABLES IN SCHEMA OLAKE_DEMO."db2_to_snowflake_shop_db2inst1";

-- Quoted identifiers: the names are lowercase, as they were in the source
SELECT "id", "name", "city", "tier"
FROM OLAKE_DEMO."db2_to_snowflake_shop_db2inst1"."customers"
ORDER BY "id";

SHOW ICEBERG TABLES reports catalog_name = SNOWFLAKE, iceberg_table_type = MANAGED and external_volume_name = SNOWFLAKE_MANAGED: Snowflake treats them as its own managed Iceberg tables, not as external tables that need a refresh.

OLake Go adds four columns to every table: _olake_id (a hash of the primary key), _op_type, _olake_timestamp and _cdc_timestamp. _op_type is r for a row from the first snapshot, c for an insert, u for an update and d for a delete. Filter them out of dashboards, or use them to see when a row last changed.

Step 7: Change rows in DB2 and sync again​

To see the incremental path work, the run on this page made 12 changes in DB2 after the first sync. Every update also sets updated_at, which is what the cursor sees:

Changes made in DB2 between the two syncs
INSERT INTO customers (name, email, city, tier) VALUES ('Maya Patel', 'maya@example.com', 'Pune', 'silver');
INSERT INTO customers (name, email, city, tier) VALUES ('Lucas Silva', 'lucas@example.com', 'São Paulo', 'bronze');
INSERT INTO orders (customer_id, product, amount, status) VALUES (9, 'Laptop', 1299.00, 'placed');
INSERT INTO orders (customer_id, product, amount, status) VALUES (9, 'Mouse', 25.50, 'placed');
INSERT INTO orders (customer_id, product, amount, status) VALUES (10, 'Monitor', 349.99, 'placed');
INSERT INTO orders (customer_id, product, amount, status) VALUES (3, 'Keyboard', 89.00, 'placed');
INSERT INTO orders (customer_id, product, amount, status) VALUES (7, 'Webcam', 79.90, 'placed');
UPDATE customers SET tier = 'gold',      updated_at = CURRENT TIMESTAMP WHERE name = 'Liam Carter';
UPDATE customers SET city = 'Abu Dhabi', updated_at = CURRENT TIMESTAMP WHERE name = 'Zara Ali';
UPDATE orders    SET status = 'delivered', updated_at = CURRENT TIMESTAMP WHERE id IN (1, 4, 7);

The second sync fetched 12 rows (635 bytes) above the saved cursor and finished in 22 seconds end to end. For customers that meant one new data file with 4 rows and one delete file retiring the 2 old versions. OLake Go's commit report shows it directly: addedDataFiles=1, addedRecords=4, addedPositionalDeleteFiles=1, addedPositionalDeletes=2, and orders the same shape with 8 rows and 3 deletes.

OLake UI sync log filtered to the Iceberg commit reports for customers and orders after the incremental sync, showing addedDataFiles 1, addedPositionalDeleteFiles 1, addedRecords 4 and 8, totalEqualityDeletes 0
The incremental sync in the OLake UI log: one data file and one positional delete file per table, zero equality deletes.

Snowflake shows the result with no refresh. Liam Carter is gold, Zara Ali moved to Abu Dhabi, and the two new customers are there. In incremental mode OLake Go cannot tell an insert from an update, so every row the second sync brought carries _op_type = u; the snapshot rows keep r:

Snowsight query on OLAKE_DEMO.db2_to_snowflake_shop_db2inst1.customers after the incremental sync showing 10 rows with _op_type r for six snapshot rows and u for Liam Carter, Zara Ali, Maya Patel and Lucas Silva
Snowsight after the incremental sync: the four rows the cursor picked up carry u, the untouched snapshot rows r.

Schema changes. When a column is added in DB2, OLake Go adds it to the Iceberg table on the next sync, and Snowflake shows it. DB2 itself may put the table in REORG PENDING after an ALTER TABLE; see troubleshooting below. Full rules are on the schema evolution page.

Query the same tables from DuckDB and Spark​

Nothing is exported, copied or refreshed: both engines read the files OLake Go wrote, through the same Horizon endpoint, with credentials vended by Snowflake.

DuckDB attaches Horizon as an Iceberg REST catalog. It wants a bearer token rather than the raw PAT, so exchange the PAT first (the curl call from the catalog setup), then attach:

DuckDB 1.5.5
INSTALL iceberg; LOAD iceberg;
INSTALL httpfs;  LOAD httpfs;

CREATE SECRET horizon_secret (TYPE iceberg, TOKEN '<access_token from /v1/oauth/tokens>');

ATTACH 'OLAKE_DEMO' AS horizon (
TYPE iceberg,
ENDPOINT 'https://<account_identifier>.snowflakecomputing.com/polaris/api/catalog',
SECRET horizon_secret,
ACCESS_DELEGATION_MODE 'vended_credentials'
);

SHOW ALL TABLES;
SELECT id, name, city, tier FROM horizon.db2_to_snowflake_shop_db2inst1.customers ORDER BY id;

The session token lives about an hour; re-run the exchange and CREATE OR REPLACE SECRET when a query fails with an authorization error. DuckDB reads deletion vectors from duckdb-iceberg 1.5.3 onward, and only attaches REST catalogs backed by S3, S3 Tables or Google Cloud Storage, so pick an AWS- or GCP-hosted Snowflake account for this path.

DuckDB 1.5.5 returned the same 10 customers, with id as INTEGER, amount as DOUBLE and the timestamps as TIMESTAMP WITH TIME ZONE.

An orders roll-up matched DB2 to the cent in all three engines. 16 delivered orders for 8659.68, 18 placed for 10522.26, 11 shipped for 6397.25.

Data types: DB2 to Iceberg to Snowflake​

OLake Go maps DB2 types to Iceberg types, and Snowflake maps Iceberg types to its own. Decimals and times are the ones to watch.

DB2Iceberg (written by OLake Go)Snowflake showsNotes
SMALLINT, INTEGERintNUMBER(10,0)
BIGINTlongNUMBER(19,0)
DECIMAL, NUMERIC, DECFLOAT, FLOAT, DOUBLEdoubleFLOATThe orders.amount sums on this page matched DB2 to the cent; round at query time when you need exact decimal arithmetic.
REALfloatFLOAT
BOOLEANbooleanBOOLEAN
DATE, TIMESTAMPtimestamptz (UTC)TIMESTAMP_LTZ(6)OLake Go writes every timestamp in UTC, whatever the server time zone.
TIMEstringVARCHAR
CHAR, VARCHAR, CLOB, GRAPHIC, VARGRAPHIC, DBCLOB, XMLstringVARCHAR
BLOBstringVARCHARBinary values arrive as text; keep large binaries out of the sync.

DB2 types in the table come from the DB2 connector reference; the Snowflake side from Snowflake's Iceberg data types page (checked 2026-10-14).

Cost and maintenance​

  • Storage is Snowflake's with SNOWFLAKE_MANAGED: you pay Snowflake storage rates for the Parquet and delete files. Point the database at your own external volume to keep the files in your bucket instead.
  • Compute. OLake Go runs wherever you run Docker, on an amd64 host for the DB2 connector. It does not use a Snowflake warehouse to write; Snowflake compute is spent only when you query.
  • DB2 load. Each incremental sync is one range scan per table on the cursor column; index UPDATED_AT so it stays cheap as the table grows. Keep RUNSTATS in your regular maintenance window so snapshot chunks stay even.
  • Maintenance. Snowflake expires old snapshots and compacts manifests on Snowflake-managed tables at no cost. Automatic data-file compaction is bundled only when Snowflake alone writes the table (Snowflake-managed Iceberg table maintenance). OLake Fusion compacts the small files each sync leaves behind, and Spark's rewrite_data_files works through the same Horizon endpoint.
  • Token rotation. The programmatic access token expires (30 days in the setup above, 365 at most). An expired token fails the next sync at the catalog handshake, before any data moves.

Troubleshooting​

1. The source test fails on an Apple silicon Mac​

image pull registry-1.docker.io/olakego/source-db2:v1.1.0: Error response from daemon: no matching manifest for linux/arm64/v8 in the manifest list entries

The OLake UI worker pulls connector images for the host's platform, and the DB2 image exists for amd64 only. Turn on Use Rosetta for x86_64/amd64 emulation in Docker Desktop, then pull the image yourself and tag it with the name the worker asks for:

bash
docker pull --platform linux/amd64 olakego/source-db2:v1.1.0
docker tag olakego/source-db2:v1.1.0 registry-1.docker.io/olakego/source-db2:v1.1.0

The run on this page hit this first and passed after these two commands. On an amd64 Linux host the error does not occur.

2. The first sync stops with "stats not populated"​

stats not populated for table[DB2INST1.CUSTOMERS]. Please run CLP command: RUNSTATS ON TABLE DB2INST1.CUSTOMERS AND INDEXES ALL

DB2 has never collected statistics for the table, and OLake Go needs them to size the snapshot chunks. Run the RUNSTATS call from step 1 for every table in the job, then sync again.

3. A sync fails with SQL0668N after an ALTER TABLE​

Adding, dropping or retyping a column can leave a DB2 table in REORG PENDING, and reads fail until it is reorganized. Run CALL SYSPROC.ADMIN_CMD('REORG TABLE db2inst1.customers'), then sync again. The DB2 connector page lists the operations that cause it.

4. The CLI picked the wrong cursor column​

discover fills cursor_field in selected_streams.json with the first column in alphabetical order. In the run on this page that was CITY for CUSTOMERS and AMOUNT for ORDERS. Set it to UPDATED_AT for every stream before the first sync; the OLake UI asks for it on the Streams page instead.

5. Updated rows are missing after an incremental sync​

The update did not move the cursor column. OLake Go only fetches rows whose cursor value is above the last one it saw. Set UPDATED_AT in every write path, or add a trigger that sets it on UPDATE.

6. Snowflake cannot find the table​

SQL compilation error:
Object 'OLAKE_DEMO.DB2_TO_SNOWFLAKE_SHOP_DB2INST1.CUSTOMERS' does not exist or not authorized.

Snowflake upper-cased an unquoted identifier. OLake Go creates the schema and tables in lower case, so quote them: OLAKE_DEMO."db2_to_snowflake_shop_db2inst1"."customers".

How this compares with other ways to move DB2 data to Snowflake
MethodFreshnessUpdates and deletesWhere the data landsWhat you run
IBM Data Replication (InfoSphere CDC)Seconds, from the DB2 logYesThe replication target you configureIBM's licensed replication engine and its target agent
Debezium's Db2 connector, Kafka and the Snowflake Kafka connectorSeconds, from SQL Replication capture tablesYesKafka topics, then Snowflake tablesKafka, Kafka Connect, Debezium, tables in capture mode and, per Debezium's docs, an IBM InfoSphere Data Replication license (checked Oct 2026)
Managed extract, load and transform (ELT) servicesMinutes, by planDepends on the plan and capture methodSnowflake tables, a second copy you pay to move and storeNothing; priced per row, per GB or per connector
Manual export (EXPORT TO ... OF DEL, then COPY INTO)Hours to dailyNo; full reloads onlyFiles you controlA script and a scheduler
OLake Go to Iceberg on Horizon (this guide)Incremental on a schedule down to one minuteInserts and updates that move the cursor; deletes need a soft-delete columnApache Iceberg tables that Snowflake, DuckDB, Spark and Trino all readOne Docker Compose stack, open source; Snowflake storage plus your own compute

Log-based replication is the choice when you need hard deletes and already hold the license. Writing Iceberg once avoids paying for a second copy as soon as another engine needs the same rows.

When not to use this​

  • You need hard deletes replicated. Incremental sync cannot see a deleted row. Soft-delete in DB2, or use a log-based tool.
  • Your DB2 runs on z/OS or IBM i. The connector covers DB2 LUW only.
  • Tables have no cursor column and cannot get one. Without a column that grows with every change, only Full Refresh works.

FAQs​

How do I replicate IBM DB2 to Snowflake without a change data capture license?

Run OLake Go (open source, Apache 2.0) against DB2 LUW with a read-only user, and point it at Snowflake's Horizon catalog. The first sync copies each table in parallel chunks; every later sync fetches only rows whose cursor column (for example UPDATED_AT) moved, and upserts them. The tables appear in Snowflake as Snowflake-managed Iceberg tables. No SQL Replication, InfoSphere Data Replication or Kafka is involved.

Does OLake Go do change data capture (CDC) from DB2 logs?

No. The DB2 connector runs Full Refresh and Full Refresh + Incremental; it does not read the DB2 log or the ASN capture tables. Incremental syncs select rows where a cursor column is greater than the last value seen, which captures inserts and updates that bump the cursor but not deletes.

Which DB2 versions and platforms does OLake Go support?

DB2 LUW (Linux, UNIX and Windows) 11.5.3 or later. The run on this page used DB2 12.1.5 in Docker. DB2 for z/OS and DB2 for i are not covered by this connector. The connector image itself runs on amd64 hosts only, because IBM's Data Server driver has no Linux arm64 build.

Why does the first sync ask me to run RUNSTATS?

OLake Go splits each table into chunks for the parallel snapshot using the row and page counts DB2 keeps in SYSCAT.TABLES. Those counts exist only after RUNSTATS has run once on the table. Run CALL SYSPROC.ADMIN_CMD('RUNSTATS ON TABLE schema.table AND INDEXES ALL') per table; statistics that are out of date do not stop a sync.

Which DB2 data types change on the way to Snowflake?

DECIMAL, NUMERIC, DECFLOAT, FLOAT and DOUBLE become Iceberg double and show up as FLOAT, so round at query time when you need exact decimal arithmetic. SMALLINT and INTEGER become int, BIGINT becomes long. DATE and TIMESTAMP become timestamptz in UTC. TIME, XML, CLOB, BLOB and GRAPHIC types arrive as VARCHAR.

Can I use AWS Glue instead of the Horizon catalog?

Yes. With Glue as the catalog the files stay in your S3 bucket, Athena, Redshift and EMR read them natively, and Snowflake reads them through a catalog integration as read-only tables you refresh after each sync. Horizon is the better default when Snowflake is the main reader, because the tables are Snowflake-managed and need no refresh.

DB2 to ClickHouseSame source, read from ClickHouse.DB2 to BigQuerySame source, read from BigQuery.DB2 to Amazon RedshiftSame source, read from Amazon Redshift.Postgres to SnowflakeSame engine, replicated from Postgres.MySQL to SnowflakeSame engine, replicated from MySQL.MongoDB to SnowflakeSame engine, replicated from MongoDB.Oracle to SnowflakeSame engine, replicated from Oracle.SQL Server to SnowflakeSame engine, replicated from SQL Server.MariaDB to SnowflakeSame engine, replicated from MariaDB.Kafka to SnowflakeSame engine, replicated from Kafka.S3 to SnowflakeSame engine, replicated from S3.DB2 connector referenceEvery field, sync mode and troubleshooting note for the source.Query engine compatibilityWhich engines read which catalogs and delete formats.All integrationsEvery source and engine pair with a tested guide.

Deeper reading on this site: