Kafka Connect and Redis: Sink and Source Connectors

Most writing about Kafka and Redis asks which one you should pick. That is the wrong question for a large share of the teams asking it, because they already run both. Kafka is the durable log that services publish to; Redis is the low-latency layer that serves reads. Two different jobs, and only one of them is the job a message broker does. The interesting question is the plumbing between them, and the usual answer is a Kafka Connect Redis connector.

This article is a current map of that plumbing. Which Redis connectors actually exist in September 2026 and which are deprecated or retired, exactly what the sink connector writes into each Redis data structure, and what the two source connectors can and cannot promise. It then covers the part the vendor documentation leaves out: what your Java code has to do to read back what the connector wrote. If you would rather settle the "which one" question first, we have that in Redis vs. Kafka and Redis Streams vs Kafka.

Why Connect Kafka to Redis at All

Four patterns cover most of what teams build, and they do not all point the same direction.

All four are ordinary data pipeline work, but direction decides the plugin. A Kafka to Redis connector is the sink; a Redis to Kafka connector is one of two sources; and they do not carry the same guarantees. What makes this worth a dedicated article is that Redis is not one destination but eight: the sink can write six core data types plus the two module types, JSON and time series. Choosing the wrong one quietly changes your delivery semantics, as the section on duplicates below shows.

The Kafka Connect Redis Connector Landscape in September 2026

This is the part that goes stale fastest, and most search results you will land on describe a 2021 world. Here is where things actually stand.

Confluent's own deprecation notice for the old Redis Sink points migrators at the Redis Inc. connector, which makes the direction of travel unambiguous. If you are starting today, start there.

One packaging detail catches people out. Redis Kafka Connect is not published to Maven Central; it ships through GitHub releases, Confluent Hub and Docker Hub. Those channels are not in step: in September 2026 Confluent Hub serves 0.9.1 against GitHub's 1.1.0. That gap is wider than a version number suggests. Version 0.9.x configures the target with redis.command (HSET, XADD, SADD and so on) and redis.key, not the redis.type and redis.keyspace used throughout this article, and it has no per-key TTL at all. Install from the GitHub release, and check which build you actually have before filing a bug about a missing feature.

Redis Data Integration, Debezium and Redpanda Connect Are Not Kafka Connect

Three tools show up in the same searches and solve adjacent problems by different means. Knowing which is which saves you from building a pipeline you did not need.

Redis Data Integration (RDI)

RDI is Redis's own change-data-capture product, and it involves no Kafka at all. It embeds Debezium Server as the collector, lands changes in Redis Streams inside an RDI staging database, and applies declarative transformations before writing to the target. The direction is source-database-to-Redis only, with an at-least-once guarantee. If your requirement is keeping Redis in sync with Postgres, RDI is a more direct answer than a Debezium-to-Kafka-to-Redis chain, and one fewer system in the path.

Debezium

Debezium's Redis integration is a sink, not a source. Debezium Server writes change events straight into Redis Streams with debezium.sink.type=redis, and Debezium can also use Redis as its offset store and its schema-history store. There is no Debezium connector that captures from Redis. If you want Redis changes in Kafka, that is the keys source connector below, with all the caveats that come with it.

Redpanda Connect

Formerly Benthos, this is a separate streaming runtime rather than a Connect plugin, with redis_hash, redis_list, redis_pubsub and redis_streams outputs. It is dual-licensed: most components, the four Redis outputs included, are Apache 2.0, while the Redpanda Community License covers the enterprise-only ones.

The Redis Sink Connector: What Actually Lands in Redis

The Redis Kafka Connect sink is configured with redis.type, and that single property decides both the shape of the write and where the Redis key comes from. Keep this table open while you configure it.

Read the "Redis key" column twice. For the three key-value types the Kafka message key is appended to the keyspace, so topic orders with message key 1001 produces the Redis key orders:1001 — redis.keyspace defaults to ${topic} and redis.separator to :. For the five collection types the Redis key is the keyspace, so an entire topic collapses into one stream, list, set, sorted set or time series. That is usually what you want, and it is occasionally a very expensive surprise.

The last column carries a caveat. The documentation says a null value removes the member from a list, set or sorted set, but in 1.1.0 the sink routes null-valued records for all five collection types to a no-op: only HASH, JSON and STRING get a real DEL. The tombstone is silently discarded for the rest. Verify against your build before you design around it.

A minimal sink that materializes an orders topic into hashes:

name=orders-sink
connector.class=com.redis.kafka.connect.RedisSinkConnector
tasks.max=2
topics=orders

redis.uri=redis://redis-1.internal:6379
redis.type=HASH
redis.keyspace=order
redis.key.ttl=86400

key.converter=org.apache.kafka.connect.storage.StringConverter
value.converter=org.apache.kafka.connect.json.JsonConverter
value.converter.schemas.enable=false

errors.tolerance=all
errors.deadletterqueue.topic.name=orders-sink-dlq
errors.deadletterqueue.context.headers.enable=true

Set redis.type explicitly even when you think you know the default. The default is STREAM — in the self-managed connector and on Confluent Cloud alike — and that is not what anyone assumes when they omit it.

The HASH and STREAM types need structured values — Avro, Protobuf, JSON Schema or plain JSON — because the connector has to turn a record value into fields, and it accepts only a struct or a map. STRING and JSON take the serialized bytes as they are, and the JSON type additionally needs the RedisJSON module, since it writes with JSON.SET. See JSON in Redis if that is new territory.

Getting that pairing wrong is a common first failure, and note where it fails. A StringConverter deserializes a JSON payload perfectly happily; the connector then rejects it inside its own write path, because the value is neither a struct nor a map. That is a failure in put(), not in the converter — a distinction that decides whether the dead letter queue below can catch it.

Reading Connector-Written Data From Java: The Codec Problem

Here is the failure that sends people to Stack Overflow. The connector runs, redis-cli shows the keys and the data looks perfect, and then the Java service reads the same key and gets an exception or nonsense.

The cause is serialization, applied independently at both ends. Kafka Connect writes through value.converter; with StringConverter or JsonConverter what lands in Redis is plain UTF-8 text. Redisson defaults to Kryo5Codec, a compact binary format. Ask Redisson for a value it did not write, with a codec that does not match how it was written, and it will try to deserialize a Kryo frame out of a JSON string.

The fix is one argument. Every Redisson object getter takes a codec, and for connector-written data that codec is StringCodec, or whichever codec matches your converter:

// WRONG - default Kryo5Codec cannot read what StringConverter wrote
RBucket<String> bad = redisson.getBucket("order:1001");

// RIGHT - tell Redisson the data is plain text
RBucket<String> good = redisson.getBucket("order:1001", StringCodec.INSTANCE);

Mapped across the sink's data structures — and every other Redis type has a Java object waiting for it — the reading side looks like this:

// redis.type=STRING
RBucket<String> bucket = redisson.getBucket("order:1001", StringCodec.INSTANCE);
String raw = bucket.get();

// redis.type=HASH - field names AND values are plain strings
RMap<String, String> hash = redisson.getMap("order:1001", StringCodec.INSTANCE);
String status = hash.get("status");

// redis.type=JSON - written with JSON.SET, so read it as JSON
RJsonBucket<Order> json =
        redisson.getJsonBucket("order:1001", new JacksonCodec<>(Order.class));
Order order = json.get();
String customer = json.get(new JacksonCodec<>(String.class), "customerId");

// redis.type=ZSET - member from the record key, score from the record value
RScoredSortedSet<String> board =
        redisson.getScoredSortedSet("scores", StringCodec.INSTANCE);
Collection<String> top10 = board.valueRangeReversed(0, 9);

// redis.type=STREAM - body is a flat map of string fields
RStream<String, String> stream = redisson.getStream("orders", StringCodec.INSTANCE);
Map<StreamMessageId, Map<String, String>> batch =
        stream.read(StreamReadArgs.greaterThan(StreamMessageId.ALL).count(100));

The JSON case rewards a second look, because path-based access lets a service pull one field out of a connector-written document without fetching the whole thing. Storing JSON in Redis on Java covers RJsonBucket and RJsonStore in full, and Redis sorted sets in Java does the same for the ZSET target.

Two refinements. If you want string field names but richer values in a hash — because you also write to the same key from Java — use new CompositeCodec(StringCodec.INSTANCE, yourValueCodec), the same technique that makes hashes indexable by Redis Search. And when iterating a large connector-populated hash, prefer the cursor-based read; HGETALL vs HSCAN explains why, and it applies here with force, because a topic-driven hash grows without anyone deciding it should.

The Redis Source Connectors: Getting Redis to Kafka

There are two, and they are not equally trustworthy.

Redis Stream Source Connector

RedisStreamSourceConnector reads a Redis stream through a consumer group and publishes to a Kafka topic. Each Kafka record carries the stream message ID as its key, and a value with id, stream and a body map of string fields.

name=events-source
connector.class=com.redis.kafka.connect.RedisStreamSourceConnector
tasks.max=2

redis.uri=redis://redis-1.internal:6379
redis.stream.name=events
redis.stream.offset=0-0
redis.stream.block=100
redis.stream.consumer.group=kafka-consumer-group
redis.stream.delivery=at-least-once
topic=redis-events

key.converter=org.apache.kafka.connect.storage.StringConverter
value.converter=org.apache.kafka.connect.json.JsonConverter

This is the source to prefer. It scales across tasks, it uses a real consumer group with a pending list, and redis.stream.delivery lets you choose at-least-once (acknowledge after the write to Kafka, the default) or at-most-once (acknowledge on read). Those are the only two options; there is no exactly-once here.

The codec trap runs in this direction too, and it is easier to miss because nothing fails loudly. The connector types the stream body as a map of strings, so if the producer is a Java service using Redisson's default binary codec, those Kryo frames are not text and will not survive the trip into a string-typed Kafka field intact. Produce with StringCodec when a connector is downstream:

RStream<String, String> stream =
        redisson.getStream("events", StringCodec.INSTANCE);

stream.add(StreamAddArgs.entries(
        "type", "ORDER_PLACED",
        "orderId", "1001",
        "amount", "49.90")
        .trimNonStrict().maxLen(1_000_000).noLimit());

Cap the stream on write. A source connector is not a reason to let a stream grow unbounded, because Redis is memory-bound and a connector that falls behind will not save you. Redis Streams in Java goes into the trimming behavior in detail, including why trimNonStrict() is the cheap path: it lets the server stop on a macro-node boundary instead of walking the log to an exact length.

Redis Keys Source Connector

RedisKeysSourceConnector watches keyspace notifications for a key pattern and publishes changes. It needs notify-keyspace-events configured, and it runs in LIVE mode (initial snapshot then updates) or LIVEONLY.

Its own documentation is blunt about the limits, and you should take them at face value. It "does not guarantee data consistency because it relies on Redis keyspace notifications which have no delivery guarantees" — notifications can be missed on network failures. It must be configured with a single task, because notifications are broadcast to every listener rather than divided round-robin. And a large, frequently-updated collection forces a full re-read on every change, so the connector can fall behind and its internal queue can fill, dropping updates.

Read that as: the keys source is a reasonable cache-invalidation signal or a development convenience. It is not a change-data-capture mechanism, and it should not be the only record that something happened. If a Java service is the consumer of those notifications rather than Kafka, subscribing to them directly from Redisson removes the connector from the path entirely. And if you need a real guarantee, have the writer publish the event itself — the outbox pattern exists precisely because inferring changes from a side channel does not hold up.

On Confluent Cloud these two are merged into one connector with a source.type of KEYS or STREAM. The managed source also requires a schema-carrying output format — Avro, JSON Schema or Protobuf — so plain JSON or string output is not an option there.

Delivery Guarantees: Choose a Data Type That Forgives Duplicates

Kafka Connect can do exactly-once, for sink connectors since Kafka 0.11.0 and for source connectors since 3.3.0 via KIP-618. Two conditions apply that matter here. Source-side exactly-once requires distributed mode and the worker property exactly.once.source.support, which defaults to disabled. And on both sides the framework cannot supply it alone: the connector has to be built to take advantage of it.

None of the Redis connectors are. Every Redis sink surveyed documents at-least-once; the stream source offers at-least-once or at-most-once; the keys source offers nothing. Duplicates are not an edge case to handle later, they are the contract.

What makes that tractable is a property of the sink that is easy to miss: whether at-least-once is harmless depends on which redis.type you chose.

If your pipeline is building current state, pick an idempotent type and the duplicate problem disappears without you writing a line of code. If you genuinely need STREAM or LIST, you need idempotency handled downstream: a dedup set keyed on an event ID, or consumers that tolerate repeats. Do not assume ordering will save you either. Multiple tasks mean multiple writers, so per-key ordering only holds if the Kafka partitioning already guarantees it.

Error Handling and the Dead Letter Queue

Connect's error handling is generic and the Redis connectors inherit it, which is one of the better arguments for using Connect at all. Four properties do the work:

The combination that bites is errors.tolerance=all with no DLQ topic configured: the pipeline looks healthy and quietly drops the records it cannot handle. Set both, always. If you are routing failures onward from Java rather than from Connect, dead letter queues and topics on Valkey and Redis covers the same pattern on the Redis side.

One documented limit is worth carrying forward, from the deprecated Confluent connector: errors.tolerance=all does not rescue a record with a null key, because the failure happens during put() before the error-handling framework can process it. That connector requires an explicit key on every record. The lesson generalizes past that one plugin, and it is the same distinction drawn earlier about value types: error tolerance covers conversion and transformation failures, not every way a connector can refuse work.

Kafka Connect Redis Configuration Traps

• redis.database defaults to 1 in the deprecated Confluent Redis Sink, while Redis itself defaults to database 0. Data lands where nobody is looking, and redis-cli without -n 1 shows an empty database.

• Cluster mode is a separate switch, and it is easy to miss. The self-managed Redis Kafka Connect exposes redis.cluster (default false), which its published documentation omits entirely; Confluent Cloud exposes redis.server.mode. Confluent is explicit about what happens when you get it wrong: a standalone client against a Redis Cluster "may throw CROSSSLOT exceptions when handling multi-key operations." The same slot rules govern your Java clients, so connecting to a Redis Cluster in Java is a useful companion before you shard a connector-fed keyspace.

• The published redis.type list has a typo. The documentation's configuration block lists SET twice and omits STRING. The enum in the source is the authority; all eight types are supported.

• Tombstones do not delete collection members. Confluent Cloud's documentation notes that for collection types "null values are excluded during insertion and not pushed to the collection." Only the key-value types delete on a null value — on Confluent Cloud as documented, and on the self-managed 1.1.0 build despite documentation that says otherwise.

• Offset management needs its own permissions. If you run Redis with ACLs, the sink needs read and write access for its own offset bookkeeping on top of the write command for your chosen type. Confluent Cloud documents this as +mset/+mget, while the self-managed connector writes offsets with MSET and reads them back with GET. Add +json.set or +ts.add for those two types, which also require the corresponding modules to be loaded.

• TLS and auth belong in the connector config, not in a wrapper. redis.uri carries credentials, and there are discrete redis.tls, redis.cacert, redis.key.file and redis.key.cert properties. Treat these as secrets in your Connect worker's config provider. The same certificate material your Java clients use will work; see connecting over TLS/SSL for the Java side.

When Not to Use Kafka Connect

Three cases where the connector is the wrong tool, stated plainly because the answer is usually "just use the connector" and that is not always right.

The source is a database. Then you want CDC, and routing it through Kafka only to land it in Redis adds a cluster to the path for no benefit. RDI or Debezium Server writing straight to Redis Streams is fewer moving parts and the same at-least-once guarantee.

The transformation is non-trivial. Single Message Transforms handle casting, key extraction and field renaming. Joining against another key, conditional routing, or anything with state is where SMT chains become a configuration language nobody wants to debug. A small consumer application is more code and considerably less cleverness.

Kafka exists only to feed Redis. If nothing else consumes the topic and retention is days rather than months, you are operating a broker cluster as a delivery mechanism. Redis Streams with consumer groups does that job; Apache Kafka alternatives weighs the options, and Is Kafka a message queue? is the shorter version of the argument.

Connecting Kafka to Redis Without Kafka Connect

If the transformation is what pushes you off Connect, the replacement is short. A Kafka consumer plus Redisson, with the writes batched so a poll of records is one network round trip rather than five hundred — pipelining, in other words, which RBatch gives you for free:

RBatch batch = redisson.createBatch();
for (ConsumerRecord<String, String> record : records) {
    RMapAsync<String, String> map =
            batch.getMap("order:" + record.key(), StringCodec.INSTANCE);
    map.putAllAsync(parseFields(record.value()));
    map.expireAsync(Duration.ofDays(1));
}
batch.execute();
consumer.commitSync();   // at-least-once: commit after the write lands

Commit after the Redis write, never before, and you have the same at-least-once contract the connector gives you, with the duplicate handling made harmless by the idempotent HASH write. What you give up is real: offset storage, task rebalancing, the DLQ machinery, and a REST API your platform team already knows how to operate. You also inherit backpressure as your own problem, since nothing throttles the consumer when Redis slows down. Weigh that before writing the consumer, not after.

For the reverse direction, a Java producer writing to a stream that a source connector lifts into Kafka, the Spring Cloud Stream binder is worth a look if you are already on Spring.

Getting Kafka's Delivery Guarantees on Redis

There is a version of the third case above where the connector is not the answer because Kafka is not the answer. Teams reach for Kafka to get retries, dead-lettering, delayed delivery and ordering, then discover they have taken on a broker fleet to obtain them.

Redisson PRO's Reliable Queue and Reliable PubSub put those guarantees on the Redis or Valkey deployment you already run. Two of them bear directly on this article. The first is deduplication by message ID or payload hash within a configurable window, which suppresses the redelivered duplicate that every Redis connector leaves you to handle yourself — the basis of the exactly-once processing Redisson documents, which is a different and more attainable thing than Kafka's exactly-once delivery. The second is a native dead-letter queue that needs no separate topic and no errors.* configuration. A message a consumer takes but never acknowledges becomes visible again when its visibility timeout expires, and once it passes the delivery limit it moves to the DLQ rather than disappearing.

RReliableQueue<Order> queue = redisson.getReliableQueue("orders");

queue.add(QueueAddArgs.messages(
        MessageArgs.payload(order)
                .deliveryLimit(3)
                .timeToLive(Duration.ofHours(1))
                .deduplicationById(order.getId(), Duration.ofHours(1))));

One caveat that costs people an afternoon: these are Redisson PRO features whose interfaces ship in the open-source jar, so code compiles against community Redisson and then throws UnsupportedOperationException at runtime. Compiling is not evidence that you have the feature. The feature comparison shows what is in each edition.

None of this is an argument against Kafka Connect. If Kafka is your system of record and Redis is your serving tier, the connector is the right plumbing and the rest of this article is about using it well.

Frequently Asked Questions

How do I connect Kafka to Redis?

Install a Kafka Connect Redis connector on your Connect workers and configure a sink. In practice that means Redis Kafka Connect: set connector.class to com.redis.kafka.connect.RedisSinkConnector, point redis.uri at your instance, list your topics, and choose redis.type to decide which Redis data structure the records become. Match key.converter and value.converter to how the topic is serialized, and remember that HASH and STREAM need a struct or a map rather than raw strings.

How do I install the Redis Kafka connector?

Not from Maven Central, which does not carry it. It is distributed through GitHub releases, Confluent Hub and Docker Hub, and those channels are not in step: Confluent Hub currently serves 0.9.1 while GitHub is on 1.1.0. The gap covers two feature releases: 0.9.x has no per-key TTL, and it configures the target with redis.command rather than redis.type, so a configuration written for 1.x will not load. Take the GitHub release unless something ties you to Hub installation.

Is there an official Kafka Connect Redis connector?

The closest thing is Redis Kafka Connect, maintained by Redis field engineering under Apache 2.0 and currently at version 1.1.0. It provides a sink connector supporting all eight Redis data structures plus two source connectors. Confluent's older Redis Sink connector is deprecated, and its documentation points migrators at the Redis Inc. connector.

Can Kafka Connect write to Redis Streams?

Yes. Set redis.type=STREAM on the sink connector and each Kafka record becomes a stream entry, with the record value forming the message body. The Redis key is the keyspace alone — the Kafka message key is not used — so an entire topic lands in one stream. The value converter must produce a struct or a map — Avro, Protobuf, JSON Schema or plain JSON — since the connector needs structure to build the entry fields.

Does the Redis Kafka connector support exactly-once delivery?

No. The sink documents at-least-once, the stream source offers at-least-once or at-most-once, and the keys source offers no guarantee at all. Kafka Connect's exactly-once support requires the connector to be built for it, and the Redis connectors are not. Design for duplicates — choosing an idempotent redis.type such as STRING, JSON or HASH makes redelivery harmless without extra code.

Why can't my Java application read the data the connector wrote?

Almost always a codec mismatch. Kafka Connect writes through its value converter, so with StringConverter or JsonConverter the data in Redis is plain UTF-8 text, while Redisson defaults to the binary Kryo5Codec. Pass StringCodec.INSTANCE when you obtain the object — redisson.getMap("order:1001", StringCodec.INSTANCE) — or a codec that matches the converter you configured.

Can Kafka Connect read changes out of Redis?

Two ways, with very different reliability. The stream source connector reads a Redis stream through a consumer group and is dependable. The keys source connector uses keyspace notifications, which its own documentation says provide no delivery guarantee; it also supports only a single task and can drop updates if its internal queue fills. Use the stream source for anything that matters.

Should I use Redis Data Integration instead of Kafka Connect?

If your goal is keeping Redis in sync with a source database, yes — RDI embeds Debezium Server and writes directly to Redis with an at-least-once guarantee, with no Kafka in the path. Kafka Connect is the right choice when Kafka is already your event backbone and Redis is one of several consumers of it.

Next Steps

The connector is the easy half; the Redis side is where the decisions live. Redis Streams in Java covers the command-level detail behind both source connectors, and data serialization codecs covers the choice that decides whether connector-written data is readable at all. For the shape of the wider system, see what a data pipeline is and stream processing.

Redisson gives Java applications typed access to every Redis and Valkey data structure through one API, whichever side of the pipeline it sits on. Redisson PRO adds the Reliable Queue and Reliable PubSub, local caching and data partitioning on top — try it for free.