Introduction

kafkacat, now commonly called kcat, is a client-side tool for producing, consuming, and inspecting Kafka data. It is not a full Kafka administration tool, so it cannot directly delete a topic or wipe all messages from a topic by itself.

That means the answer depends on what you really want to do. Deleting the topic entirely is one operation. Keeping the topic but removing its data is a different operation, and neither one is something kcat is designed to perform directly.

kcat Does Not Delete Topics

If the goal is to remove the topic itself, use Kafka's admin tooling:

1kafka-topics.sh \
2  --bootstrap-server localhost:9092 \
3  --delete \
4  --topic my-topic

This requests topic deletion from the broker. Whether it actually works depends on broker configuration, especially whether topic deletion is enabled.

The key point is that kcat is not the right tool for this. Topic administration belongs to Kafka admin commands or admin client APIs.

Deleting All Messages Is Not the Same as Deleting the Topic

Sometimes the real need is to keep the topic but clear its current contents. That is a different operational task.

Common approaches include:

• using Kafka's delete-records tooling for controlled truncation
• temporarily lowering retention so old segments expire quickly
• deleting and recreating the topic in development or test environments

Which one is right depends on whether preserving topic metadata and configuration matters.

Delete Records Deliberately

Kafka provides a delete-records operation that trims partitions before chosen offsets. That is more precise than deleting the whole topic, but it requires understanding offsets clearly.

Example offset file:

1{
2  "partitions": [
3    { "topic": "my-topic", "partition": 0, "offset": -1 }
4  ],
5  "version": 1
6}

Then:

kafka-delete-records.sh \
  --bootstrap-server localhost:9092 \
  --offset-json-file delete-records.json

This is powerful, but it is easy to misuse if you do not know the partition layout and the offsets you intend to trim.

The Retention Shortcut

A common operational shortcut is to temporarily reduce retention so the broker cleans up data quickly:

1kafka-configs.sh \
2  --bootstrap-server localhost:9092 \
3  --entity-type topics \
4  --entity-name my-topic \
5  --alter \
6  --add-config retention.ms=1000

After Kafka purges the old segments, restore the normal retention:

1kafka-configs.sh \
2  --bootstrap-server localhost:9092 \
3  --entity-type topics \
4  --entity-name my-topic \
5  --alter \
6  --delete-config retention.ms

This is often acceptable in development, but it should not be treated as a casual production habit.

Recreate the Topic in Development

In a non-production environment, the simplest path is often:

1. delete the topic
2. recreate it with the intended partition and replication settings

kafka-topics.sh --bootstrap-server localhost:9092 --delete --topic my-topic
kafka-topics.sh --bootstrap-server localhost:9092 --create --topic my-topic --partitions 3 --replication-factor 1

That is usually easier to reason about than record truncation if you do not care about preserving the topic's history.

Common Pitfalls

The biggest mistake is expecting kafkacat or kcat to perform administrative deletion. It is the wrong tool for that job.

Another common issue is confusing topic deletion with message deletion inside a topic. The operational impact is very different.

Developers also sometimes lower retention in production without thinking through the effect on replay, auditing, and consumer recovery.

Finally, if the real problem is consumer position rather than topic contents, resetting consumer offsets may be the correct fix instead of deleting data at all.

Summary

• 'kcat does not directly delete topics or wipe all topic messages.'
• Use Kafka admin tooling such as kafka-topics.sh to delete a topic.
• Use delete-records or retention changes when you need to clear data but keep the topic.
• Recreating the topic is often the simplest approach in development environments.
• Before deleting data, verify that the real issue is the topic contents and not consumer offsets.