Skip to content

Commit e5a7e0c

Browse files
committed
3.5.0.Final Announcement: Update What's Next
Signed-off-by: Chris Cranford <chris@hibernate.org>
1 parent 7210d29 commit e5a7e0c

File tree

1 file changed

+28
-2
lines changed

1 file changed

+28
-2
lines changed

_posts/2026-03-31-debezium-3-5-final-released.adoc

Lines changed: 28 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -55,7 +55,7 @@ This guarantees that any code reorganization across different versions does not
5555

5656
The following covers all new features and improvements, grouped by connector or component area.
5757

58-
[cols="25%,23%,28%,24%"]
58+
[cols="25%,22%,28%,25%"]
5959
|===
6060
|link:#new-features-and-improvements-debezium-core[Debezium Core]
6161
|link:#new-features-and-improvements-debezium-db2[Debezium for Db2]
@@ -811,4 +811,30 @@ It's hard to believe we're already a quarter of the way through the year, but th
811811

812812
Now as we begin to turn our attention to Debezium 3.6, and what lies in store for the end of Q2, we'd like to take a moment and share a sneak peek into what our plans are for that release:
813813

814-
**TBD**
814+
Core - Pluggable relational schema management::
815+
Debezium's connectors are powerful, but in large-scale deployments this comes with high memory overhead, especially when capturing changes across multiple databases or schemas sharing identical table layouts.
816+
With pluggable relational schema management, we're putting control back in the hands of users, enabling custom strategies for how the relational model is maintained, which can drastically reduce the connector memory footprint and unlocking leaner, more efficient deployments at scale.
817+
818+
Core - Decouple from Kafka::
819+
Kafka was the foundation Debezium was built on, and for good reason.
820+
But after a decade of growth, the ecosystem has evolved, and Debezium should too.
821+
With a decoupled core, we're embarking on one of the most ambitious architectural evolutions in Debezium's history and once that most likely will take multiple iterations to reach.
822+
Our goal is to untether the internals from Kafka, while keeping everything you rely on today fully intact.
823+
This gives Debezium the freedom to adapt to market trends, new technologies, and innovation in today's landscape.
824+
825+
Quarkus Extensions - Advanced filtering::
826+
The Debezium Quarkus Extensions already provide a lot of functionality out of the box, but when it comes to fine-grained control over which events to process, users deserve more than topic-level filtering.
827+
With advanced filtering, we're bringing native Quarkus CDI-based approaches directly into the Extensions, giving developers the expressive, intuitive control they expect from the Quarkus ecosystem, whether that means handling only update events, filtering by payload, or crafting complex multi-condition rules that fit exactly the use case at hand.
828+
829+
Debezium Server - Native builds::
830+
With the focus the last six months to make Debezium's source connectors build as native Quarkus applications, the next chapter of that story is the evolution of Debezium Server.
831+
With native builds of Debezium Server, we intend to bring the power and scalability of Debezium's Quarkus Extensions to Debezium's Kubernetes solution.
832+
833+
Platform - Built-in Observability::
834+
With visibility into your pipelines being just as critical as the pipelines themselves, Debezium Platform is taking observability to the next level.
835+
With built-in observability, we're bringing a fully integrated monitoring stack directly into the Platform, giving teams the real-time insight and diagnostic power they need to keep their data pipelines running at their best.
836+
837+
Oracle - Multi-threaded Stream Processing::
838+
Debezium's connectors have traditionally been single-threaded, but as Oracle transaction concurrency and volume grow, the interconnected nature of mining and processing can potentially become a bottleneck; especially with multi-node Oracle clusters.
839+
With a memory-mapped queue-based architecture, we plan to explore decoupling the LogMiner reader and processing into independent threads, replacing the heap-based memory buffer with a lightweight commit-log style solution.
840+
This will dramatically reduce the memory pressure for large and concurrent transactions, while yielding more granular operational visibility needed to run Debezium at scale with Oracle.

0 commit comments

Comments
 (0)