Kafka Rust Clients: rdkafka vs rskafka vs krafka

Among the clients compared here, rdkafka leads crates.io downloads by a wide margin: about 7.7 million in the 90 days to 8 Oct 2026, more than ten times any pure Rust client. It wraps the librdkafka C library, so a default build compiles librdkafka from C source.

The pure Rust clients skip that build step but differ in scope and maturity. rskafka reads and writes individual partitions and has no consumer groups. krafka supports consumer groups and transactions, but the project was created in February 2026. kafka-rust, published as the kafka crate, last shipped in September 2023 and matters mainly to services that already use it.

This guide compares rdkafka, rskafka, and krafka for new projects and covers migration from kafka-rust. It looks at build requirements, consumer groups, transactions, authentication, default partitioners, and Schema Registry integration, with capabilities checked against specific releases.

Quick decision

If you use Avro, Protobuf, or JSON Schema with a schema registry, pair your chosen client with a registry crate; none of these clients bundles Schema Registry serializers. See Schema Registry in Rust.

librdkafka wrapper or pure Rust?

rdkafka gives a Rust service the same producer, consumer group, and transaction code that Confluent's Go, Python, and .NET clients use. The trade-off is native build and deployment requirements. By default, rdkafka compiles librdkafka from C source and links it statically:

• Toolchain: The default build needs a C compiler, GNU make, and pthreads. The README encourages the cmake-build feature, which needs CMake. On Windows, the build requires cmake-build.
• Native libraries: TLS and SASL/SCRAM need the ssl feature (OpenSSL), and Kerberos needs gssapi (Cyrus SASL). These and zlib link against system libraries unless you enable ssl-vendored, gssapi-vendored, or libz-static.
• Cross-compiling: Building for another target or for musl needs a C toolchain for that target. Test the binary inside the production container image.

Tip: To skip compiling librdkafka, enable the dynamic-linking feature to link an installed copy instead. The installed version must be at least as new as the bundled one, and the shared library must also be available at runtime.

rskafka and krafka avoid librdkafka and OpenSSL and use rustls for TLS. Their default feature sets still require a C toolchain: krafka enables ring, while rskafka enables lz4 and zstd codecs backed by C libraries. rskafka also uses ring when transport-tls is enabled, and krafka's optional zstd feature adds another C dependency. Cross-compiling requires the corresponding target toolchain. kafka-rust's default security feature links OpenSSL.

Choose based on protocol coverage and release maturity, then check whether the native dependencies fit your build and deployment environment. Among the pure Rust clients compared here, only krafka covers consumer groups and transactions, and it is the youngest of the four.

Kafka Rust clients compared

Capabilities verified against each release's source and documentation: 8 Oct 2026

KIP-848 moves partition assignment to the broker and is production-ready in Kafka 4.0 and later. It is a separate feature from cooperative-sticky rebalancing under the classic protocol. rdkafka and krafka support both protocols and still default to the classic one. rskafka and kafka-rust do not join consumer groups.

rdkafka

rdkafka is a safe Rust interface to librdkafka. Release 0.39.0 (25 Jan 2026) bundles librdkafka 2.12.1, so the behavior of the protocol comes from that C library. Configuration uses librdkafka property names, such as bootstrap.servers, through ClientConfig.

Capabilities and limitations

• API: StreamConsumer and FutureProducer fit into async code. BaseConsumer and BaseProducer must be polled from your own loop, and ThreadedProducer polls on a background thread.
• Protocol coverage: librdkafka provides idempotent and transactional producers, read_committed consumers, and an AdminClient.
• Consumer commits: librdkafka commits every 5 seconds by default, and it can commit a record that your code has not finished. For at-least-once processing, set enable.auto.offset.store=false and call store_offset_from_message after each record is processed.
• Consumer groups: Set partition.assignment.strategy=cooperative-sticky for incremental rebalances. librdkafka made KIP-848 generally available in 2.12.0; enable it with group.protocol=consumer on Kafka 4.0+.
• Default partitioner: consistent_random hashes keys with CRC32. Set partitioner=murmur2_random for Java-compatible key-to-partition mapping, or implement the Partitioner trait for custom placement.
• AWS MSK IAM: Implement ClientContext with ENABLE_REFRESH_OAUTH_TOKEN = true and override generate_oauth_token to supply MSK IAM tokens through SASL/OAUTHBEARER. The community aws-msk-iam-sasl-signer crate, a port of AWS's Go signer, includes rdkafka examples.
• Maintenance: The repository snapshot shows no default-branch commits or merged PRs in 90 days and 50 open PRs. With the default static build, librdkafka fixes require an updated rdkafka-sys bundle and a rebuild. With dynamic-linking, the installed shared library can be updated separately.

When to choose: Choose rdkafka for production services that need consumer groups, transactions, or GSSAPI, and whose build and deployment environment can support librdkafka's native dependencies. It has by far the most crates.io downloads of the four.

rskafka

rskafka is a minimal client that InfluxData wrote for using Kafka as a write-ahead log. Its README states that InfluxDB 3.0 originally used it but no longer does. The latest release is 0.6.0 (20 Mar 2025).

Capabilities and limitations

• Model: You get a PartitionClient for one topic partition, then produce to it or fetch from it at an offset. There is no partitioner, so your code decides where each record goes.
• Missing by design: No consumer groups, offset commits, or transactions.
• Producer: PartitionClient::produce sends the supplied records as one batch. BatchProducer combines multiple produce calls using an Aggregator and a configurable linger timeout. There is no idempotent producer support, so retries can produce duplicates.
• Consumer: StreamConsumer reads one partition from a start offset and advances its read position in memory. To resume after a restart, persist the next offset after processing, for example in your own database.
• Security: TLS through rustls needs the transport-tls feature, which is off by default. SASL PLAIN, SCRAM-SHA-256/512, and OAUTHBEARER are supported, and transport-socks5 adds a SOCKS5 proxy.
• Admin: The controller client can create and delete topics.

When to choose: Choose rskafka for workloads that manage offsets outside Kafka and read or write a small number of high-throughput partitions. Do not choose it for a service that needs consumer groups.

krafka

krafka is a pure Rust, Tokio-based client. Its repository was created on 6 Feb 2026, and it has published 32 crates.io releases since then, the latest being 0.26.0 (6 Oct 2026). The coverage below comes from the project's own documentation and source; test it against your brokers.

Capabilities and limitations

• Coverage: Idempotent and transactional producers, classic and KIP-848 consumers, a KIP-932 share consumer (Kafka 4.2+), and an AdminClient. It requires Kafka 3.9 or later.
• Consumer commits: Auto-commit is enabled with a default interval of 5 seconds and commits positions advanced by poll(), which may include records still being processed. For at-least-once processing, disable auto-commit and call commit() after processing the entire batch returned by poll(), before polling again.
• Consumer groups: Choose KIP-848 with .group_protocol(GroupProtocol::Consumer) on Kafka 4.0+. The default is still Classic.
• Default partitioner: The default UniformStickyPartitioner hashes keys with Murmur2 for Java-compatible key-to-partition mapping. Records without keys use sticky partitioning to build batches on one partition. Set a custom partitioner with .partitioner(...).
• Security: TLS and mTLS through rustls; SASL PLAIN, SCRAM, and OAUTHBEARER; and AWS MSK IAM, with the aws-msk feature adding the AWS SDK credential chain. GSSAPI is out of scope.
• Stability: krafka is pre-1.0, and minor releases can carry breaking changes. Pin the version and read the Breaking section of each changelog entry before upgrading. The minimum Rust version is 1.95.
• Maintenance: The repository snapshot shows the most commits and merged PRs of the four. Two commit authors were active in the past year, and one account merged every PR.

When to choose: Choose krafka when you want to avoid librdkafka and the service still needs consumer groups, transactions, or MSK IAM. Allow time for API changes when upgrading.

kafka-rust

kafka-rust, created in 2015, is the oldest client in this guide. It is published on crates.io as kafka, so Cargo.toml lists it as kafka = "0.10". Its README says: "Use it in production at your own risk."

Capabilities and limitations

• API: Producer and Consumer are blocking. There is no async API.
• Protocol versions: 0.10.0 sends version 0 of Produce, Fetch, and ListOffsets, and it only parses the oldest message format, which has no headers. Kafka 4.0 removed those request versions (KIP-896), so 0.10.0 cannot produce to or fetch from Kafka 4.0+ brokers.
• Consumer groups: The group name is used only to store offsets. Consumers do not join a group or rebalance, so each instance reads the partitions it was configured with.
• Consumer commits: Offsets are not committed automatically. After processing every record in a message set, call consume_messageset to mark it consumed, then call commit_consumed to persist the offsets.
• Default partitioner: Keys are hashed with XxHash32 and placed by hash % partition_count. Records without keys go round-robin over partitions that have a leader.
• Security: TLS through OpenSSL. 0.10.0 has no SASL support, and compression covers gzip and Snappy only.
• Release status: The master branch carries 0.11.0, with a changelog entry dated 2 Jul 2026 that adds rustls and SASL/PLAIN. As of 8 Oct 2026 it has no tag or crates.io release. Produce, Fetch, and ListOffsets still use version 0, so these changes do not resolve Kafka 4.0 compatibility.

When to choose: Do not start new work on kafka-rust. If a service already uses it, plan the move before its brokers reach Kafka 4.0.

Two other crates come up in searches:

• kafka-protocol (0.18.0) generates types for the Kafka wire protocol but is not a client. It suits proxies and tools that speak the protocol directly.
• samsa is another pure Rust client with consumer groups, TLS, and SASL. Its last release, 0.1.8, shipped in September 2025, and it had 3,488 downloads in the 90 days to 8 Oct 2026.

Schema Registry in Rust

None of the four clients ships Schema Registry serializers. They hand your code bytes, and a separate crate encodes and decodes them:

These crates are independent of the Kafka client: encode before producing and decode after consuming. Header-based schema identifiers require record-header support, which kafka-rust 0.10.0 lacks.

Check each crate's Cargo features for optional codecs, registry backends, and rule executors.

Whichever you pick, check the framing against records written by your other services. Confluent's schema-ID payload format starts with a zero magic byte and a 4-byte schema ID, for both keys and values. Protobuf adds message indexes identifying the message type before the encoded payload.

Moving from kafka-rust

kafka-rust 0.10.0 cannot produce to or fetch from Kafka 4.0+ brokers, so moving is a question of timing. Pick the destination first:

• rdkafka: The most mature option, if your build and deployment environment can support librdkafka's native dependencies. BaseConsumer and BaseProducer let you keep a blocking, thread-per-consumer design.
• krafka: Avoids librdkafka, but you adopt a young, pre-1.0 API and Tokio.

Then check each behavior that changes:

• Group membership: kafka-rust consumers with the same group name do not coordinate. If you switch to group subscription, instances with the same group ID share partitions. Decide whether you want group subscription or explicit partition assignment.
• Commits: kafka-rust commits only when you call commit_consumed. rdkafka and krafka commit automatically by default, so set up commits after processing if the old code depended on that.
• Starting offset: Set auto.offset.reset in rdkafka or auto_offset_reset in krafka explicitly. Both default to the latest offset when a group has no committed offset.
• Existing offsets: If the old consumer stored offsets in Kafka (GroupOffsetStorage::Kafka), a new consumer with the same group ID should resume from them. Before reusing the group ID, let the old consumers finish the records they have fetched, commit offsets, and stop; then start the new consumers. Confirm this on a test topic before the cutover.
• Null and empty data: kafka-rust's Producer converts empty keys and values to None. Preserve that behavior explicitly when migrating: an empty key was keyless, and an empty value was a tombstone on compacted topics.
• Headers: The new producer can send record headers. Consumers that still run kafka-rust 0.10.0 cannot read them.

Finally, check key placement. kafka-rust places a record with a non-empty key at XxHash32(key) % partition_count, using a zero seed. rdkafka defaults to CRC32 and krafka to Murmur2, so the same key usually lands on a different partition after the switch. That can break per-key ordering across the cutover.

You have two options:

• Keep the old placement: Implement a custom partitioner that computes the same 32-bit XxHash with seed 0, then takes the remainder by the partition count. Use rdkafka's Partitioner trait or krafka's .partitioner(...).
• Switch to Java placement: Accept a one-time move of keys to Murmur2. Use krafka's default or rdkafka's partitioner=murmur2_random. Stop the old producers and drain their records before starting producers with the new partitioner.

Either way, produce representative records with the old and new producers to a test topic with the same partition count. Compare partition placement for non-empty keys, and verify that empty and null keys and values preserve the old behavior.

GitHub repository metrics

The tables below compare the four clients' GitHub activity, maintenance, and public usage, with crates.io downloads as the usage signal. Snapshot: 8 Oct 2026.

Project overview

Licenses are taken from each crate's Cargo.toml. GitHub shows only one of the two license files for the dual-licensed crates.

Activity

Maintenance

PR merge distribution counts non-bot mergedBy accounts. It does not measure reviewer or maintainer headcount. None of the four crates has a RustSec advisory.

Public usage and interest

Downloads include CI builds and transitive dependencies, not unique users. Dependent crates covers only crates published on crates.io.

Overall repository signals

• rdkafka leads crates.io downloads by a wide margin, with 7,657,245 downloads in 90 days and 304 dependent crates, but it had no default-branch commits or merged PRs in the last 90 days, and 50 open PRs have a median age of 1 year.
• rskafka had 756,862 downloads in 90 days but only 17 dependent crates; 4 PRs merged in 90 days with a median merge time of 5.5 hours, and it has not published to crates.io since 0.6.0 in March 2025.
• krafka is the most active by far, with 54 commits and 15 merged PRs in 90 days and 32 crates.io releases since February 2026, but it is the youngest project, with 20,369 downloads in 90 days and two commit authors.
• kafka-rust has not published to crates.io since 0.10.0 in September 2023; master prepared 0.11.0 in July 2026, but that version is untagged and unpublished. It had no commits or merged PRs in the last 90 days; its 48 open issues have a median age of 5 years, yet it still had 142,602 downloads in 90 days.

In all four repositories, one account handled every recorded PR merge in the past year. These are maintenance and adoption signals, not evidence of runtime quality or feature fit.

Test Rust Kafka clients with Kafma

A clean cargo build does not show which partition a key reached, what bytes a producer wrote, or what a consumer does with a record it cannot decode. All four clients hand keys and values to your code as bytes, so decoding and tombstone handling live in your code.

Kafma is a desktop Kafka GUI that runs alongside your Rust service. Its Kafka console gives you one client-independent place to inspect producer output, send controlled records, and watch a consumer group's committed position.

Compare partitions for the same keys

Produce the same keys from the old and new producers to a test topic with the same partition count. In Kafma, compare each record's key and partition. A kafka-rust producer and an rdkafka or krafka producer will usually place the same key on different partitions unless you reproduce the XxHash32 placement.

Check Schema Registry framing

When a consumer cannot decode a record, open it in Kafma. With Schema Registry configured, Decoded shows the value resolved through its schema ID, and Raw shows the original bytes as hexadecimal. Browse subjects and versions in Kafma's Schema Registry UI, then compare their schema IDs with the record.

If your consumer expects the Confluent payload-prefix format, Raw should start with 00 followed by a four-byte schema ID. If it starts with plain JSON or text instead, the schema prefix is missing. Check whether the producer intentionally puts schema IDs in headers before treating the record as unframed.

Test consumer errors and shutdown

Use a test topic without an automatic schema binding, because Kafma validates input against a schema bound by topic name. Keep the consumer running and use the producer panel to send, to one partition: a valid record, a payload your decoder rejects, a tombstone, and another valid record. Choose String or Bytes for the invalid payload and Null for the tombstone.

Check whether the invalid payload is retried, skipped, or stops processing, and whether the final record is processed and committed. Handle null values explicitly: unwrapping a tombstone's value panics, and inside a spawned Tokio task the process can keep running while that consumer silently stops.

For consumers that join a group, use Loop to keep records arriving, then send the service SIGTERM. Open Watch Group and check that the member leaves, assignments settle, and the committed offset points to the next record after the last one processed. Kafma reads this state without joining the group or committing offsets; its consumer group UI shows lag across every member.

Clone data for migration tests

Kafma Data Clone copies a selected range of real records to a test topic. Use it to exercise older schema versions, missing headers, tombstones, and other cases that hand-written fixtures miss. It can copy keys, values, timestamps, and headers, register required schemas, and mask selected fields.

Copied records receive new offsets and may land on different partitions. Use the clone to check decoding and consumer behavior, and compare partitions with records produced directly by the old and new clients. See the Data Clone guide for copy behavior.

Download Kafma and connect to the same test cluster as the Rust service.

Frequently asked questions

Is there an official Apache Kafka client for Rust?

No. Apache Kafka's first-party client is Java, and Confluent does not publish a Rust client. rdkafka is a community-maintained wrapper around Confluent's librdkafka, and rskafka, krafka, and kafka-rust are independent pure Rust implementations.

Can I build rdkafka without a C compiler?

Not with the default features, which compile librdkafka from source. The dynamic-linking feature links a librdkafka that pkg-config can find instead, and that library must then be installed on every runtime host. rskafka and krafka avoid librdkafka, but their default feature sets still compile native dependencies and require a C toolchain.

Does kafka-rust work with Kafka 4.0?

No. Release 0.10.0 sends version 0 of the Produce, Fetch, and ListOffsets requests, and Kafka 4.0 removed those versions under KIP-896. The unreleased 0.11.0 on master still uses version 0. See Moving from kafka-rust.

Which Rust Kafka clients support KIP-848?

rdkafka 0.39.0 and krafka 0.26.0, both on Kafka 4.0+. In rdkafka, set group.protocol=consumer; the bundled librdkafka 2.12.1 includes the generally available implementation. In krafka, use .group_protocol(GroupProtocol::Consumer). rskafka and kafka-rust do not support consumer group membership at all.

Which Rust Kafka client works with AWS MSK IAM?

krafka supports AWS MSK IAM directly; enable the aws-msk feature for the AWS SDK credential chain. rdkafka can connect through SASL/OAUTHBEARER using tokens from the community aws-msk-iam-sasl-signer crate; see rdkafka for the token callback configuration. rskafka and kafka-rust have no built-in MSK IAM support.

Do Rust Kafka clients partition keys the same way as Java?

krafka does by default, using Murmur2. rdkafka needs partitioner=murmur2_random, because its default uses CRC32. kafka-rust uses XxHash32, which no other client matches without a custom partitioner. rskafka has no partitioner; your code chooses the partition.

Is rdkafka still maintained?

The repository is not archived, and 0.39.0 shipped on 25 Jan 2026. However, the 8 Oct 2026 snapshot found no default-branch commits or merged PRs in the preceding 90 days and 50 open PRs with a median age of 1 year. Recent activity in the Rust wrapper is limited. Much of the protocol work happens upstream in librdkafka.

Conclusion

For most production services, start with rdkafka: it has librdkafka's mature consumer groups and transactions and by far the most crates.io downloads of the four. Choose krafka when you want to avoid librdkafka and can accommodate API changes during upgrades. Use rskafka for explicit partition-level reads and writes, managing offsets yourself when consuming.

If you still run kafka-rust, plan the move before your brokers reach Kafka 4.0, and compare where keyed records land before the new producer takes over.

This guide is maintained by the team behind Kafma.