---
title: "Kafka batch.size: how producer batching works"
description: "What Kafka producer batch.size controls, its 16384-byte default, how it works with linger.ms and compression, and what a larger batch costs. Simulated live."
url: https://monedula.dev/kafka-simulator/configs/batch-size/
---

# batch.size: the producer batch limit

Producer config · default 16384 (bytes) · Apache Kafka 4.3.

batch.size is the most bytes the Kafka producer puts in one batch for a single partition (default 16384, 16 KiB). A batch is sent when it is full or when linger.ms runs out, whichever comes first, so batch.size caps a batch rather than making the producer wait for one.

## At a glance

- Config: `batch.size` (producer)
- Default: 16384 (bytes)
- Valid values: 0 or more; 0 turns batching off
- Reference: [Apache Kafka documentation](https://kafka.apache.org/43/configuration/producer-configs/#producerconfigs_batch.size)

## What it does

Each partition the producer writes to has its own open batch, carved out of buffer.memory. Records are appended until the next one would not fit, and then the batch is ready to send. Ready batches for partitions led by the same broker travel together in one produce request. A single record larger than batch.size gets a batch of its own. With compression on, the producer counts the estimated compressed size against batch.size, so a compressed batch holds more records.

## The trade-off

A larger batch.size means fewer requests and better compression, so more throughput and less broker load, but every partition in use can hold a batch of that size, so many partitions times a large batch.size can exhaust buffer.memory. A smaller one sends more, smaller requests. On its own a larger batch.size adds no latency: only linger.ms makes the producer wait.

## Advice

- For throughput, raise batch.size (64 KiB to 256 KiB is common) together with linger.ms; one without the other changes little.
- Check buffer.memory against the number of partitions the producer writes to at once.
- Do not set 0: every record then goes out in a batch of its own.

## See it in the simulator

- [Kafka linger.ms vs batch.size: when the producer sends](https://monedula.dev/kafka-simulator/scenarios/linger-and-batch-size/) (linger.ms and batch.size), step 4: batch.size reached · 3-record batch flushed at once. O3, O4, O5 arrived in a burst and hit batch.size=3 (three records here; real batch.size is 16384 bytes by default), so the batch flushed immediately - without waiting out linger.ms (LEO 5). Bigger batches → fewer requests → more throughput, at the cost of a little latency. [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=01.2.1&t=3)
- [Kafka compression.type: fewer, larger producer batches](https://monedula.dev/kafka-simulator/scenarios/compression-and-batch-shape/) (Compression and batch shape), step 3: Batch 2 of 2 (no compression). A4-A6 fill a second 3-record batch - offsets 3,4,5. Six records → TWO produce requests. Here batch.size=3 caps every batch at 3 records (the simulator counts records; real batch.size is a byte budget). [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=01.2.3&t=2)

## Related configs

- [Kafka linger.ms: batching latency vs throughput](https://monedula.dev/kafka-simulator/configs/linger-ms/)
- [Kafka compression.type: gzip vs snappy vs lz4 vs zstd](https://monedula.dev/kafka-simulator/configs/compression-type/)
- [Kafka max.in.flight.requests.per.connection explained](https://monedula.dev/kafka-simulator/configs/max-in-flight-requests-per-connection/)