Popsink vs Qlik Replicate for IBM i (AS/400) replication

‍

Introduction: a bit of history

‍

Qlik Replicate's history starts out with ISG International Software Group in 1988, which rebranded to Attunity in 2001. Over the years, it specialized in data replication, CDC, and integration tools, eventually becoming well-known for Attunity Replicate before being acquired by Qlik in 2019. Attunity Replicate was subsequently rebranded to Qlik Replicate. Today, Qlik offers it as part of its broader data integration suite, alongside Qlik Data Catalog, Qlik Compose, and lately, Talend.

Popsink was founded in 2021 with the goal of addressing the limitations of older replication tools when applied to modern data platforms and hybrid architectures. From the start, Popsink specialized in real-time Change Data Capture (CDC) with a focus on non-intrusive integration and mission-critical data systems such as IBM i, Oracle, and SAP, while ensuring compatibility with cloud-native platforms like Snowflake, Databricks, and Kafka.

‍

Why the capture method matters

‍

IBM i, still often referred to as the AS/400, isn’t just another database server - it’s the backbone of day-to-day operations in many enterprises. Payments clear, shipments move, and policies are issued on these machines. Because of this, they are treated with extreme caution: any instability directly threatens the business.

How changes are captured from these systems is therefore not a technical footnote but a central concern. A replication method that adds too much CPU load can slow down the very transactions the system exists to process. On the other hand, an approach that delivers changes with minimal delay can feed fraud detection engines, supply chain dashboards, or AI models while events are still unfolding.

In practice, the choice of CDC technique sets the balance: IT teams see the effect in terms of stability and resource consumption, while business users experience it in the speed and accuracy of the data they rely on. This post compares two approaches for IBM i Change Data Capture (CDC):

‍

‍- Qlik Replicate (using ODBC + SQL for both snapshots and change capture - through QSYS2.DISPLAY_JOURNAL user-defined table function)

‍

- Popsink (leveraging JDBC + SQL for snapshots and raw binary streaming for change capture)

‍

The focus is on output quality, throughput, CPU footprint, and reliability at scale: the factors that matter most when CDC is part of your operational core.

‍

Architecture & Methodology

‍

‍

Performance & Throughput

‍

Order-of-Magnitude Example: 100,000 journaled row changes per minute

‍

‍

Why RPC Wins:
By reading journal receivers directly, Popsink avoids the SQL engine’s row materialization step. This cuts CPU cycles and keeps the stream closer to real-time, even as volume spikes.

‍

CPU Impact on the IBM i

‍

‍

Source: Estimates based on IBM’s documented overhead for DISPLAY_JOURNAL vs QjoRetrieveJournalEntries in high-volume tests as reported by user tests and industry case studies.

‍

Reliability at Scale

‍

‍

Permissions & Security

‍

On IBM i, replication tools only work if the right authorities are granted, but the scope of those permissions differs significantly between approaches.

Popsink runs against the journal subsystem directly, so the user profile only needs rights to the journal objects themselves: USE and OBJEXIST on the journal, EXECUTE on its library, and USE on the receivers. Nothing more is required—no SQL catalog access, no privileges on system UDTFs.

Qlik Replicate, by contrast, relies on the QSYS2.DISPLAY_JOURNAL function through ODBC. That means the replication user must be able to connect via DRDA, issue SQL queries, and hold SELECT authority on the UDTF in addition to underlying journal access. In practice, this grants broader reach into the SQL engine and metadata than Popsink requires.

The difference is simple: Popsink is limited to the journals it’s told to read, while Qlik Replicate needs a SQL-level key that opens the door to more of the system.

‍

Strategic Considerations

‍

Business Continuity‍

High CPU impact on IBM i can jeopardize transaction processing. Popsink’s lighter footprint leaves more headroom for business-critical workloads.

‍

Real-Time Decisioning‍

Whether for fraud prevention, just-in-time supply chain, or live analytics, a 2–5 second lag can mean lost opportunities or risk exposure. Popsink’s sub-second potential is a strategic enabler.

‍

Scalability‍

SQL-based CDC often scales non-linearly, doubling change volume can more than double CPU usage. RPC-based capture scales linearly and predictably.

‍

Audit & Compliance‍

Regulatory scenarios (e.g., SOX, PSD3) require exact replication of source changes. Popsink preserves all journal data, eliminating ambiguity.

‍

Security implication

‍With Popsink, privileges are limited to the exact journals being read, reducing the attack surface compared to granting broad ODBC/SQL access.

‍

Conclusion

Both Popsink and Qlik Replicate achieve the same end goal—moving data off IBM i into modern platforms—but the way they do it makes a material difference.

Popsink connects to the journal service directly, which means changes are streamed with low latency, minimal CPU overhead, and complete fidelity. That makes it well suited for environments where volumes are high and business processes depend on timely, uninterrupted replication.

Qlik Replicate, by contrast, leans on SQL to fetch journal data. This design introduces extra processing cost and can become resource-heavy at scale. It works, but it tends to fit better in cases where volumes are moderate and the risk of higher system load is acceptable.

For organizations that rely on IBM i as the foundation of daily operations, the capture method is more than a technical preference, it defines whether replication strengthens stability and responsiveness -or becomes another point of stress for the system.