Popsink vs Fivetran HVR for IBM i (AS/400) replication

‍

Introduction: Why the Capture Method Matters for Both IT and Business

‍

IBM i (formerly known as AS/400) continues to run core processes in key industries like finance, insurance, logistics, or manufacturing, where reliability is non-negotiable. The operational data these systems generate is most valuable when it reaches analytics platforms, AI pipelines, and operational dashboards in near real time. The method used to capture and replicate that data directly affects latency, system load, scalability, and the ability to act on information when it matters most.

‍

The gap between a low-latency, high-fidelity stream and a slower, CPU-heavy process can decide:

- If a fraud detection system blocks a suspicious transaction within seconds or only after it’s too late.

- If planning dashboards show current inventory or outdated figures.

- If the production system stays responsive under heavy change volumes or suffers degraded performance from CDC overhead.

‍

For IT leaders, the replication method directly impacts system reliability, scalability, and operational risk. For business leaders, it affects speed to insight, responsiveness to events, and competitive advantage.

‍

This post compares two approaches for IBM i Change Data Capture (CDC):

- Popsink (leveraging the same journal-based RPC method as Debezium)

- Fivetran HVR (ODBC + SQL, using QSYS2.DISPLAY_JOURNAL)

‍

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

‍

‍

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.

‍

Conclusion

‍

Both Popsink and HVR can replicate from IBM i to modern platforms, but how they capture changes has decisive effects on performance, scalability, and business outcomes.

- Popsink’s journal RPC method offers higher throughput, lower CPU impact, and full fidelity - making it the clear choice for high-volume, latency-sensitive, and business critical workloads.

- HVR’s SQL-based method is more CPU-intensive and slightly less complete but can be viable for less critical workloads where CPU usage and business continuity are not critical.

In environments where IBM i remains mission-critical and operational risk is tightly managed, the replication method is not just a technical detail - it’s a strategic choice that determines whether CDC is an enabler or a bottleneck.

‍