Adding Kafka Partitions and Deleting Records

Partitions control how Kafka distributes records and parallelizes consumption. Kafma can increase a topic's partition count or remove its retained records without deleting the topic. Neither operation can be undone.

How Kafka topics and partitions work

A Kafka topic contains one or more partitions. Each partition is an ordered log with its own offsets. Kafka guarantees record order within a partition, not across the whole topic.

Within a consumer group, each partition is assigned to one member at a time. Adding partitions can increase consumption parallelism, but only when the group has enough members to use them.

Add partitions to a Kafka topic

Open the topic's action menu and select Add Partitions, or click Add in the topic details drawer. Enter the new total partition count, not the number to add. The value must be greater than the current count.

Kafka can add partitions to a live topic, but it cannot remove them. To return to a lower count, create another topic and migrate the records.

Key routing and ordering

Keyed records are routed using the producer's partitioner and the available partition count. After the count changes, the same key may map to a different partition. Existing records stay where they are.

Records for one key can therefore be split between its old and new partitions. Kafka provides no ordering guarantee between them. If an application depends on per-key ordering to rebuild state, creating a new topic and replaying into it is safer than expanding the existing topic.

Compacted Kafka topics

Compaction runs independently in each partition. If a key moves after partitions are added, its old value and new value can remain in different partitions. A consumer rebuilding state may then encounter both.

Delete records from a Kafka topic

Kafma can delete records from the entire topic or from one partition. Both actions use Kafka's Delete Records operation to move the selected partitions' low watermarks to their current high watermarks. The records become unreadable, while Kafka reclaims their storage asynchronously.

The topic's cleanup.policy must include delete, so delete-only and mixed-policy topics are supported. The action is unavailable on compact-only topics and read-only connections.

Delete all retained records

From the Topics list, open the topic's action menu and select Delete Records. Kafma truncates every non-empty partition to the high watermark captured when the operation starts.

This clears or purges the records retained at that point. The topic, its partitions, and its configuration remain, and producers can continue writing new records.

Clear one partition

Open the topic details drawer and hover over a partition to reveal the clear icon. Click it, review the number of records that will be deleted, and confirm. Kafma truncates that partition to its current high watermark without changing the other partitions.

Why you cannot delete one message

Kafka's Delete Records API can only remove a contiguous prefix before a specified offset in each partition. It cannot remove one record from the middle while preserving the records around it.

Kafma does not currently expose a custom cutoff offset. The topic action uses the current high watermark for every non-empty partition, while the partition action uses the selected partition's current high watermark. The selected topic or partition is therefore cleared completely.

What consumers see after deletion

A consumer group may have a committed offset below the new low watermark. Its next fetch then returns OFFSET_OUT_OF_RANGE, and the consumer's auto.offset.reset setting determines what happens:

• earliest resumes from the new earliest offset.
• latest resumes at the end.
• none returns an error.

Deleting records does not delete consumer groups or reset their committed offsets. Check the topic's Consumers section before clearing data that an application still needs.

Next steps

• Browse and inspect Kafka topics
• Create a Kafka topic
• Read messages from a topic