Kafka JavaScript Clients: KafkaJS vs. Platformatic Kafka

KafkaJS has long been a familiar choice for Node.js applications that want a JavaScript API without a native addon. Platformatic Kafka offers a newer pure-JavaScript client with stream-based consumers and support focused on current Node.js releases. confluent-kafka-javascript provides a Promise-based API influenced by KafkaJS and backed by librdkafka, while node-rdkafka remains relevant for applications that use its lower-level native interface.

This guide compares the four clients' Node.js support, native dependencies, consumer processing models, serialization options, Schema Registry support, and migration costs. A separate set of GitHub metrics shows recent maintenance activity and visible public usage.

Quick decision

Tip: These clients provide Kafka messaging, not stateful stream processing. For windows, joins, or managed state stores, use a dedicated framework such as Apache Flink or Kafka Streams.

Kafka JavaScript clients compared

Versions and capabilities checked against official documentation and npm metadata on 28 Aug 2026.

All four clients also support TLS and mutual TLS.

Platformatic Kafka

Platformatic Kafka is a pure TypeScript/JavaScript client for current Node.js releases. Its consumer returns a Readable stream, making for await...of, stream composition, and Node.js backpressure part of the consumer design.

Capabilities and limitations

• Kafka and tooling: Version 2.11.0 supports Kafka 3.5 through 4.2, including the KIP-848 consumer group protocol, with implemented features listed in a KIP support matrix. It includes serializers, bigint offsets and timestamps, and node:diagnostics_channel integration.
• Schema Registry: Built-in Avro, Protobuf, and JSON Schema support is experimental and can change outside a major release.
• Deployment constraints: It requires Node.js 22.22+ or 24.6+ and supports PLAIN, SCRAM, and OAUTHBEARER, but not GSSAPI/Kerberos. Consumer streams default to a highWaterMark of 1024 messages, which should be reduced for large records. The project also publishes benchmarks that you can use as a reference for your own testing.

When to choose Platformatic Kafka

Choose Platformatic Kafka for a new service that can run on a current Node.js release and needs KIP-848 without a native addon or benefits from stream-based consumption. Choose another client if the deployment requires GSSAPI/Kerberos or stable Schema Registry APIs.

KafkaJS

KafkaJS is a pure JavaScript client with a Promise-based API and eachMessage and eachBatch consumer handlers. It supports older Node.js releases without a native addon.

Capabilities and limitations

• Protocol and authentication: KafkaJS supports producers, transactions, headers, and an Admin client, plus PLAIN, SCRAM, and OAUTHBEARER authentication, but not GSSAPI/Kerberos. Amazon MSK IAM works through AWS's signer package and an OAUTHBEARER token provider. KafkaJS uses classic consumer groups with a built-in round-robin assigner; custom assigners are possible, but KIP-848 and a built-in cooperative-sticky assigner are absent.
• Compression and schemas: GZIP compression is included; Snappy, LZ4, and ZSTD require additional codec packages, and Schema Registry support comes from a separate KafkaJS package. KafkaJS decompresses records but does not expose the original compression codec on consumed messages.
• Release status and Node.js 24: The latest release is version 2.2.4, published in February 2023. On Node.js 24, it can schedule a 1 ms timer loop on idle connections, causing a TimeoutNegativeWarning and unnecessary CPU use.

When to choose KafkaJS

Keep KafkaJS when an existing application is stable and does not need GSSAPI/Kerberos, a built-in cooperative-sticky assigner, or KIP-848. For a new pure JavaScript service, prefer Platformatic Kafka if its runtime and stream model fit; choose Confluent's client when librdkafka features, first-party Schema Registry support, or commercial support matters.

confluent-kafka-javascript

confluent-kafka-javascript combines librdkafka with a KafkaJS-influenced Promise API. It retains eachMessage and eachBatch and also provides a callback API derived from node-rdkafka.

Capabilities and limitations

• Kafka features: Version 1.10.0 includes librdkafka 2.15.0, so Kafka 4 deployments can use KIP-848. GZIP, Snappy, LZ4, and ZSTD require no additional JavaScript codec packages, and authentication supports GSSAPI/Kerberos in addition to PLAIN, SCRAM, and OAUTHBEARER.
• Packaging and schemas: Confluent publishes prebuilt binaries for supported Linux, macOS, and Windows combinations, while Yarn and pnpm support remain experimental. Unsupported targets may require node-gyp and a C/C++ toolchain. Schema Registry support comes from the first-party @confluentinc/schemaregistry package.
• KafkaJS compatibility: The compatible layer reduces migration work but does not support custom producer partitioners, custom consumer assigners, or consumer.stop(), and its Admin API covers only a subset of KafkaJS methods.

When to choose confluent-kafka-javascript

Choose Confluent's client when a new service needs GSSAPI/Kerberos, first-party Schema Registry support, commercial support, or the closest maintained migration path from KafkaJS. Verify binary availability for every development and production target.

node-rdkafka

node-rdkafka exposes librdkafka configuration through event-driven producers and consumers, callbacks, stream helpers, delivery reports, and transactions.

Capabilities and limitations

• Kafka features: Version 3.6.1 includes librdkafka 2.12.0, which supports KIP-848 with Kafka 4 brokers. Authentication follows librdkafka and includes GSSAPI/Kerberos, while the direct configuration surface suits applications that depend on native callbacks and settings.
• Producer and Admin APIs: The standard Producer API must call poll() or configure setPollInterval(); otherwise, delivery reports are not emitted and the internal queue can eventually fill. The Admin client creates and deletes topics and increases partition counts but does not expose librdkafka's configuration-alteration APIs.
• Deployment: The native addon must be tested on every target. Linux and macOS are the main supported platforms, while Windows support may lag. Confluent's newer client shares this lineage but provides a documented prebuilt-binary support matrix and a Promise-oriented API.

When to choose node-rdkafka

Keep node-rdkafka when an existing application relies on its API or direct librdkafka configuration. For a new service, choose Confluent's client unless the lower-level event or stream interface is a specific requirement.

Migrating from KafkaJS

This guide covers two practical migration paths for KafkaJS applications. confluent-kafka-javascript retains much of the KafkaJS API and usually requires fewer application changes, but it introduces a native addon. Platformatic Kafka has no native addon, but consumer processing must be rewritten around Node.js streams.

Amazon MSK IAM: KafkaJS uses an external AWS signer through OAUTHBEARER. Before migrating, verify the target client's token-provider and token-refresh integration.

Migrating from KafkaJS to Platformatic Kafka

Platformatic provides a detailed KafkaJS migration guide. The migration changes both APIs and application behavior.

The consumer rewrite is the main migration risk. Test partition ordering, commit timing, rebalances, and graceful shutdown with in-flight records.

Producer migration also needs wire-level verification. A serialization change can alter message keys, JSON encoding, headers, or Schema Registry framing even when the TypeScript values look equivalent.

Migrating from KafkaJS to confluent-kafka-javascript

Confluent provides an official KafkaJS migration guide for its compatibility layer. The main processing APIs remain familiar, but configuration placement and some runtime behavior differ.

Applications using transactions need an additional check: a transactional producer cannot send outside an active transaction, and sendOffsets() receives the consumer instead of a consumer group ID.

Code churn is lower than with Platformatic, but verify rebalance, commit, retry, and error semantics and native binaries on every target.

Repository signals

The tables below compare the four clients' GitHub activity, maintenance, and public usage using the same metrics and assessment rules. Snapshot: 28 Aug 2026.

Project overview

Activity

Release figures cover GitHub Releases, not npm. Confluent's latest GitHub entry is a prerelease; the capability table uses the stable 1.10.0 release.

Maintenance

PR merge distribution counts non-bot mergedBy accounts, so automated merges may undercount human reviewers. Issue closure rates use issues opened 90–180 days before the snapshot, giving each issue a full 90-day window.

Public usage and interest

GitHub dependents are approximate public-repository counts.

Overall repository signals

• Platformatic Kafka has the strongest recent activity, but it is the youngest project, has limited visible adoption, and recorded PR merging is concentrated among two people.
• KafkaJS has by far the broadest visible adoption, but its default branch and releases are inactive and its issue and PR backlogs are old.
• confluent-kafka-javascript is active and PR merging is distributed across more contributors, but visible adoption remains limited and its PR backlog is aging.
• node-rdkafka has established visible adoption, but it has no recent commits or merged PRs and recorded PR merging is concentrated in one person.

These are maintenance and adoption signals, not evidence of runtime quality or performance.

Test JavaScript Kafka clients with Kafma

A resolved send() does not prove that the stored bytes, headers, or schema framing match downstream expectations.

Kafma lets you inspect Kafka records and send controlled test traffic from one desktop workspace, without writing temporary debugging scripts.

Inspect records and test consumers in Console

Run your application producer against a test topic, then inspect the record in Kafma:

• Check encoding: With Schema Registry configured, Kafma automatically decodes Avro, Protobuf, and JSON Schema records. Switch between Decoded and Raw to verify the decoded value, schema ID, and original bytes.
• Check metadata: Verify the stored key, headers, partition, offset, and timestamp, especially after changing serializers or header mappings.

Keep the application consumer running, then use Kafma's built-in producer to send controlled test records:

• Manual: Send edge-case payloads, tombstones, custom headers, or fixed-partition records.
• File: Load CSV, JSON, or JSONL data for repeatable batch tests. Available with Kafma Pro.
• Loop: Generate continuous test traffic while observing batching, backpressure, and shutdown with in-flight records.

Clone production-shaped data for migration tests

Simple test data rarely reflects everything in a production topic. Older schema versions, tombstone records with null values, unusual keys, and missing headers can expose migration problems.

Kafma Data Clone copies a bounded time or offset range into a local or staging cluster. With Structure + Data, it can create a missing target topic, register the required schemas, and copy keys, values, timestamps, headers, and tombstones. Optional masking can redact selected sensitive fields.

Frequently asked questions

Should an existing KafkaJS application migrate?

Keep KafkaJS if the application is stable and its feature set and maintenance path remain acceptable. Choose confluent-kafka-javascript when you need KIP-848, GSSAPI/Kerberos, first-party Schema Registry support, or commercial support with fewer API changes. Choose Platformatic Kafka when staying pure JavaScript matters and the application can adopt its Node.js requirements and stream-based consumer.

Is a pure JavaScript client always easier to deploy?

It usually simplifies packaging by avoiding platform-specific native binaries. Runtime compatibility still matters: Platformatic Kafka requires Node.js 22.22+ or 24.6+, while KafkaJS supports older Node.js versions.

Which clients support the KIP-848 consumer group protocol?

Platformatic Kafka, confluent-kafka-javascript, and node-rdkafka support KIP-848; KafkaJS does not. KIP-848 requires Kafka 4.0+ brokers. For the two librdkafka clients, set group.protocol=consumer; the classic protocol remains the default. Treat adoption as a consumer migration and test configuration, assignments, rebalances, and commits.

Does librdkafka automatically make a client faster?

No. Throughput depends on message size, batching, compression, acknowledgements, network latency, consumer concurrency, and application overhead. Benchmark the complete workload with comparable settings.

Can services using different JavaScript clients share a topic or consumer group?

They can share a topic when they agree on key and value serialization, headers, Schema Registry framing, and partitioning assumptions. Consumers sharing a group must also use the same group protocol and compatible assignment behavior; test rebalances and offset commits before mixing clients in production.

Conclusion

For a new pure-JavaScript service, start with Platformatic Kafka when its Node.js requirements and stream-based consumer fit. Choose confluent-kafka-javascript when you need a KafkaJS-like API, GSSAPI/Kerberos, first-party Schema Registry support, or commercial support. Keep KafkaJS or node-rdkafka in a stable existing service unless a missing capability justifies migration.

This guide is maintained by the team behind Kafma.