Limits & Rules

Two kinds of limit apply to the connector: hard limits (fixed in code, not configurable — protecting the wire protocol and the channel-injectivity guarantees reference/topic-mapping depends on) and operator-configurable caps (the CONNECTORS_KAFKA_* settings that bound per-topic, per-request, and per-connection resource use). Both are listed here; the full field-by-field settings reference — including fields not covered by this page, like transaction timeouts and byte-rate quotas — lives at Configuration reference.

Hard limits (not configurable)

A violation of either rule is a config-time or admin-time rejection, never a silent clamp — see Notes on the trickier ones below.

Operator-configurable caps (CONNECTORS_KAFKA_*)

Server-side settings in [Connectors.Kafka]; env vars use the CONNECTORS_KAFKA_* prefix. Defaults and ceilings below are the connector's own floor/ceiling pair — an unset or non-positive value falls back to the default (there is no "unbounded" mode on any of these), and a value above the ceiling is rejected at server startup.

Notes on the trickier ones

• 256 partitions is a hard ceiling with no override. CreateTopics with NumPartitions > 256 is rejected INVALID_PARTITIONS. CreatePartitions follows the same rule for growth: Count must strictly exceed the topic's current partition count — a same-count or lower Count is also rejected INVALID_PARTITIONS (never shrink, never no-op), and a Count above 256 is rejected the same way. A partition increase, once accepted, is durable and cannot be reversed. See Partitions & Ordering for the ordering consequences of growing partition count on an existing topic.
• One batch versus one request. A Produce request carries one batch per partition, so a producer writing 20 partitions sends 20 batches in one frame. MaxMessageBytes limits each batch and MaxRequestBytes limits the frame; the frame limit is never lower than one batch's, so raising MaxMessageBytes can never make a legal batch unsendable.
• MaxMessageBytes's 1 GiB ceiling is a safety bound, not a recommendation. Kafka frames are length-prefixed by a 32-bit integer; the ceiling keeps MaxMessageBytes comfortably below the point where the frame-length arithmetic could wrap. Most deployments should raise the 1 MiB default modestly (a few MiB) rather than approach the ceiling.
• Per-topic max.message.bytes is echo-only. DescribeConfigs and IncrementalAlterConfigs accept and reflect a topic-level max.message.bytes override, but enforcement always uses the broker-wide MaxMessageBytes above (default 1 MiB, operator-raisable up to the 1 GiB ceiling) — a topic config can never raise the enforced limit.
• MaxConnections fails closed at the TCP layer, not the Kafka protocol layer. Because Kafka has no in-band "too many connections" response, a client at the cap sees a plain connection refusal — indistinguishable, on the wire, from the port being closed. Size MaxConnections for your real client fleet (each consumer, producer, and admin tool holds at least one connection) before relying on it as a guardrail.
• OffsetsRetentionMinutes is a retention rule, not a request-time limit. Unlike the other rows, exceeding it produces no error at all — a consumer group's committed offset simply ages out and is treated as absent (falls back to auto.offset.reset) the next time that group is described or resumes.
• ScramIterations only matters if you run SASL/SCRAM. It is read once, at connector construction, to derive each configured user's SCRAM verifier — raising it strengthens brute-force resistance at a one-time boot cost, never a per-authentication cost.

Related