---
title: "Kafka delete.retention.ms: how long tombstones stay"
description: "What Kafka delete.retention.ms does on a compacted topic: how long a tombstone survives compaction, its 1-day default, and why consumers must read within it."
url: https://monedula.dev/kafka-simulator/configs/delete-retention-ms/
---

# delete.retention.ms: tombstones on compacted topics

Topic config · default 86400000 (1 day) · Apache Kafka 4.3.

delete.retention.ms is how long a compacted topic keeps a tombstone, a record with a null value that deletes its key, after compaction has removed the older values of that key (default 86400000, 1 day). Once it passes, the next compaction removes the tombstone too. A consumer that reads the topic from the start must finish within that window, or it may never see the delete.

## At a glance

- Config: `delete.retention.ms` (topic)
- Default: 86400000 (1 day)
- Valid values: 0 or more (milliseconds)
- Also set at: The broker-wide default is log.cleaner.delete.retention.ms (also 1 day).
- Reference: [Apache Kafka documentation](https://kafka.apache.org/43/configuration/topic-configs/#topicconfigs_delete.retention.ms)

## What it does

On a topic with cleanup.policy=compact, deleting a key means producing a tombstone for it. The log cleaner keeps only the latest record per key, so the tombstone survives while the values before it are removed. delete.retention.ms is the grace period the tombstone then stays in the log, so consumers that read the topic, such as a service rebuilding a cache or a table from it, learn that the key was deleted. After the grace period the cleaner drops the tombstone and the key leaves no trace.

## The trade-off

A longer delete.retention.ms gives slow or rebuilding consumers more time to see every delete, at the cost of tombstones taking space and showing up in every full read. A shorter one keeps the log lean, but a consumer that starts reading from the beginning and takes longer than the window can miss a tombstone and keep a deleted key in its state forever.

## Advice

- Keep delete.retention.ms longer than the longest time a consumer needs to read the whole topic from offset 0, including restores and rebuilds.
- Remember that the clock starts at compaction, not at produce time, and compaction only touches closed segments, so tombstones usually stay longer than the setting.
- Do not set it to 0 on a topic that consumers rebuild state from.

## See it in the simulator

- [Kafka tombstones: deleting a key with delete.retention.ms](https://monedula.dev/kafka-simulator/scenarios/tombstones-delete-retention/) (Tombstones & delete.retention.ms), step 4: Tombstone lingering (grace window). Mid grace window: the tombstone still sits in the log. delete.retention.ms keeps it long enough for a consumer that reads within the window to observe the delete before it vanishes. [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=05.2.2&t=3)
- [Kafka log compaction: cleanup.policy=compact explained](https://monedula.dev/kafka-simulator/scenarios/compaction/) (Compaction), step 2: Compacted · older keys collapsed. Each key keeps only its latest offset; offsets 0-2 are removed and survivors keep their original offsets (gaps). The user-2 tombstone lingers during delete.retention.ms. Real Kafka never compacts the active segment, so these records would first have to roll into a closed one. [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=05.2.1&t=1)

## Related configs

- [Kafka cleanup.policy: delete vs compact (and both)](https://monedula.dev/kafka-simulator/configs/cleanup-policy/)
- [Kafka retention.ms: time-based retention explained](https://monedula.dev/kafka-simulator/configs/retention-ms/)
- [Kafka retention.bytes: size-based retention per partition](https://monedula.dev/kafka-simulator/configs/retention-bytes/)