anchor.diff:  
   I am happy to announce the release of Debezium *1.9.0.Beta1*!
   
  -This release includes many new features for Debezium Sink including Knative event support,
  +This release includes many new features for Debezium Server, including Knative Eventing support and
   offset storage management with the Redis sink,
  -multi-partitioned SQL Server scaling,
  +multi-partitioned scaling for the SQL Server connector,
   and various of bugfixes and improvements.
   Overall, https://issues.redhat.com/issues/?jql=project%20%3D%20DBZ%20AND%20fixVersion%20%3D%201.9.0.Beta1%20ORDER%20BY%20component%20ASC[56 issues] have been fixed for this release.
   
  
positive.code: 
  +++<!-- more -->+++
  
  == Debezium Server Knative events
  
  Debezium Server has grown quite a lot since its introduction to the Debezium portfolio in version 1.2.
  In this release, we have added a new sink implementation to support Knative eventing.
  
  Knative eventing provides tools and infrastructure to route events from a producer to consumers, in a very similar way in which Apache Kafka allows the exchange of events via message topics.
  With Debezium Server, you can now leverage the new https://github.com/debezium/debezium/tree/main/debezium-server/debezium-server-http[debezium-server-http] sink to deliver Debezium change events to a Knative Broker, a Kubernetes resource that defines a mesh for collecting and distributing https://cloudevents.io/[CloudEvents] to consumers.
  
  In order to get started with Debezium and Knative eventing, you simply need to configure the Debezium Server with your desired source connector and then configure the sink side with the following:
  
  ```properties
  debezium.sink.type=http
  
negative.code: debezium.sink.http.url=https://<hostname>/<end-point>
  ```
  
  We're super excited about this new sink connector and we look forward to all your feedback.
  A big thank you to https://github.com/cab105[Chris Baumbauer] for this excellent contribution!
  
  == Redis-managed Offsets for Debezium Server
  
  Several folks from https://redis.com/[Redis] stepped up lately for improving the story around integrating Debezium and https://redis.io/topics/streams-intro[Redis Streams].
  After the performance improvements done in 1.9.0.Alpha1 (by means of batching),
  another result of that work is the ability to link:/documentation/reference/1.9/operations/debezium-server.html#debezium-source-offset-storage[store connector offsets] in Redis.
  For the next 1.9 early access release you can expect a database history implementation backed by Redis,
  and the team also is working on implementing retry support for Debezium Server.
  Thanks a lot to https://github.com/spicy-sauce[Yossi Shirizli],
  https://github.com/zalmane[Oren Elias] and all the other Redis folks contributing not only to the Redis Streams sink, but also to Debezium and Debezium Server at large!
  
  == Multi-partitioned Scaling for SQL Server Connector
  
  Some database platforms, such as SQL Server and Oracle, support the creation and management of multiple logical databases within a single physical database server instance.
  Traditionally, streaming changes from the multiple logical databases required a separate connector deployment.
  Now there isn't anything innately wrong with such a deployment strategy, but it can quickly start to show its shortcomings if you have many logical databases;
  for instance in case of multi-tenancy scenarios with one logical database per tenant,
  the overhead of setting up and operating one connector per database can become a bottleneck.
  Besides that, processing change events from multiple logical databases lends itself perfectly well to parallelization by means of Kafka Connect's concept of tasks.
  
  Over the last several 1.x releases, a tremendous amount of work has gone into key fundamental changes to Debezium's common connector framework, setting the stage for a new horizontal scaling strategy.
  
  One of the initial goals of this new strategy is to eliminate the need for multiple connector deployments when streaming changes from multiple logical databases within a single SQL Server instance.
  Additionally, it was critical to expose metrics in a way that enables monitoring tools to report on the state and health of the connector both from a connector-centric perspective but also from each logical database being processed.
  In this release, we've achieved those goals.
  
  But this is just the beginning folks!
  