conduktor.io ↗

enable.auto.commit — Kafka Consumer Configuration

If true the consumer's offset will be periodically committed in the background..

Description

If true the consumer's offset will be periodically committed in the background.

Default Values by Kafka Version

Kafka VersionDefault Value
0.9.0true
0.10.0true
0.10.1true
0.10.2true
0.11.0true
1.0true
1.1true
2.0true
2.1true
2.2true
2.3true
2.4true
2.5true
2.6true
2.7true
2.8true
3.0true
3.1true
3.2true
3.3true
3.4true
3.5true
3.6true
3.7true
3.8true
3.9true
4.0true
4.1true
4.2true

Tuning Recommendation

ProfileRecommendedWhy
consumer / throughputtrueAuto-commit eliminates the overhead of manual commitSync() or commitAsync() calls in the hot processing path. For pure throughput workloads where at-least-once reprocessing on restart is acceptable, auto-commit with a 5s interval is the lowest-overhead commit strategy.
consumer / latencyfalseDisable auto-commit and use manual commitAsync() after processing each batch. This ensures offsets are only committed after records are processed, preventing loss of processed-record tracking and enabling precise at-least-once semantics. For latency-critical consumers, auto-commit's 5s interval can cause 5s of reprocessing on restart, spiking latency during recovery.
consumer / durabilityfalseAuto-commit is fundamentally incompatible with strong durability: it commits offsets on a timer regardless of whether records have been successfully processed. If the consumer crashes between auto-commit and processing completion, those records are silently skipped. Manual commitSync() after confirmed processing is the only safe pattern for durable consumers.

Related Configs

auto.commit.interval.ms · isolation.level · auto.offset.reset · max.poll.records · partition.assignment.strategy

Manage Kafka configs across all your clusters with Conduktor Console — view, compare, and update configurations in one place.