auto.offset.reset — Kafka Consumer Configuration
What to do when there is no initial offset in Kafka or if the current offset does not exist any more on the server (e.g.
Description
What to do when there is no initial offset in Kafka or if the current offset does not exist any more on the server (e.g. because that data has been deleted):
Default Values by Kafka Version
| Kafka Version | Default Value |
|---|---|
| 0.8.0 | largest |
| 0.8.1 | largest |
| 0.8.2 | largest |
| 0.9.0 | largest |
| 0.10.0 | largest |
| 0.10.1 | latest |
| 0.10.2 | latest |
| 0.11.0 | latest |
| 1.0 | latest |
| 1.1 | latest |
| 2.0 | latest |
| 2.1 | latest |
| 2.2 | latest |
| 2.3 | latest |
| 2.4 | latest |
| 2.5 | latest |
| 2.6 | latest |
| 2.7 | latest |
| 2.8 | latest |
| 3.0 | latest |
| 3.1 | latest |
| 3.2 | latest |
| 3.3 | latest |
| 3.4 | latest |
| 3.5 | latest |
| 3.6 | latest |
| 3.7 | latest |
| 3.8 | latest |
| 3.9 | latest |
| 4.0 | latest |
| 4.1 | latest |
| 4.2 | latest |
Tuning Recommendation
| Profile | Recommended | Why |
|---|---|---|
| consumer / latency | latest | latest is the correct default for latency-sensitive consumers: on first start or offset loss, the consumer begins from the tip of the partition rather than replaying the full history. Starting from earliest would introduce unbounded startup latency as the consumer catches up on historical data. |
| consumer / durability | earliest | For durable consumers, offset loss (e.g., after consumer group deletion or offset retention expiry) must result in reprocessing from the beginning, not skipping forward to latest. earliest guarantees no records are missed on first startup or offset reset. Monitor for this case explicitly via consumer_group_offsets metrics. |
Related Configs
enable.auto.commit · isolation.level
Manage Kafka configs across all your clusters with Conduktor Console — view, compare, and update configurations in one place.