Debezium 3.6.0.CR1 Released: RocksDB Memory, Faster MySQL CDC, and Spanner Omni

AIDeveloper44 Team

Change Data Capture (CDC) has become an indispensable component of modern data architecture, serving as the nervous system for real-time analytics, event-driven microservices, and live data ingestion for AI systems like Retrieval-Augmented Generation (RAG). Today, the Debezium community has hit another major milestone with the release of Debezium 3.6.0.CR1.

As the first candidate release in the 3.6 cycle, this version packs a significant punch. It delivers highly anticipated memory management optimizations, expanded database compatibility, and polished user experience enhancements within the Debezium Platform. Let’s dive into the core updates that developers and data engineers need to know.

Debezium Core: Taming Heap Memory with RocksDB

One of the most persistent challenges when scaling CDC pipelines is managing the memory footprint of internal schema histories and table mappings. For connectors tracking thousands of tables, storing this metadata entirely in heap memory often leads to excessive garbage collection overhead and potential instability.

To solve this, Debezium 3.6 introduces a new pluggable interface that externalizes table mapping storage. Out of the box, it provides a RocksDB-based implementation that pushes table history and schema mappings to disk rather than consuming Java heap memory (dbz#2015). This off-heap memory management allows connectors to handle massive schema topologies gracefully, ensuring stable throughput without memory pressure.

MySQL: Massive Drops in CPU and Allocation Overhead

Performance tuning on the hot path is always a welcome update. In the Debezium for MySQL connector, the doPoll() method—which is repeatedly called by Kafka Connect—historically used a Java stream and collector pipeline to unwrap DataChangeEvent objects into SourceRecord instances.

In this release, the stream pipeline has been swapped out for a pre-sized ArrayList and a direct loop (dbz#2113). The results are staggering:

• ~75% reduction in memory allocation on the poll path.
• 31% to 42% reduction in CPU overhead.
• For a default max.batch.size of 2048, per-operation allocation drops from roughly 34 KB to just 8 KB.

By drastically reducing garbage collection pressure, MySQL CDC deployments under sustained load will experience smoother, more consistent latency profiles.

Oracle Enhancements: Deferred Transactions and Unified Drivers

Debezium’s robust Oracle support gets several critical quality-of-life and performance upgrades in 3.6.0.CR1:

• Deferred Transaction Creation: A new mode allows the connector to hold off on creating a transaction in the buffer until the first DML event actually occurs (dbz#2046). This filters out "stub" transactions (transactions with just START and COMMIT/ROLLBACK but no DML), which are common with SQL developer tools. Because the mining window now slides forward block-by-block, this reduces the memory footprint, though users should evaluate the trade-offs regarding transaction re-mining.
• Unified JDBC Driver: Previously split across versions 21.15 and 23.3.x, the connector now consolidates onto a single Oracle 23.26.x driver that is backward compatible with Oracle 19 and 21 (dbz#1837).
• Smarter Diagnostics & Retries: If log gathering fails, Debezium now checks V$ARCHIVED_LOG to explicitly tell you if a log was purged, rather than just stating it's missing (dbz#1532). Additionally, XStream adapter attach retries now utilize an exponential back-off strategy for cleaner, more reliable connections (dbz#2031).
• RAC Environment Filtering: Logs from PRIVATE and DISABLED redo threads are now properly filtered out, preventing unnecessary SCN mining window extensions and false-positive missing log errors (dbz#2049).

Debezium Platform: Dashboards, APIs, and JDBC Sinks

The visual and operational experience of managing Debezium pipelines via the Debezium Platform continues to mature.

The Conductor now boasts a Monitoring REST API that queries Prometheus time-series data and transforms it into a highly compact JSON array format—reducing payload sizes by roughly 53% (dbz#1898). This API powers a brand-new multi-panel monitoring dashboard in the pipeline overview UI (dbz#2025). Driven by React Query for shared caching, users can visualize metrics via PatternFly charts, control global time ranges, and enjoy resilient rendering even if a single metric panel fails to load.

Additionally, Debezium Platform users can now construct sink pipelines using the Debezium JDBC sink connector directly from the UI (dbz#2079), allowing for seamless, end-to-end database replication configurations without touching code.

Expanded Cloud Horizons: Spanner Omni Compatibility

For organizations operating outside the Google Cloud ecosystem, Google’s release of Spanner Omni—a version of Spanner that runs on other clouds or on-premises—was a game-changer. Debezium 3.6.0.CR1 officially introduces Spanner Omni compatibility (dbz#1858). Data engineers can now leverage the exact same proven Spanner CDC connector to stream changes regardless of where their Omni deployment is physically hosted.

Wrapping Up

Alongside these marquee features, the release includes fixes for KafkaSchemaHistory recovery race conditions (dbz#2032), PostgreSQL varbit handling, and CockroachDB temporal alignments. In total, 44 issues were squashed in this release candidate.

Debezium 3.6.0.CR1 showcases a deep commitment to not just feature breadth, but operational depth—making CDC more memory-efficient, CPU-friendly, and visually observable. As we push toward the final GA release, it’s a perfect time to fire up this candidate in your staging environments and see the performance gains firsthand.

Enjoyed this?

Get more posts like this delivered to your inbox.

Subscribe