Apache Cassandra
Batch Operations: Logged vs Unlogged
Learn the correct use cases for CQL batches and why batching is not a general-purpose performance optimization in Cassandra.
In a relational database a batch is a performance optimisation. In Cassandra it is usually the opposite, and this catches out almost everyone arriving from SQL.
A logged batch is like a courier who writes a receipt listing everything they promised to deliver before setting out, so if they get hit by a bus halfway through, someone else can finish the deliveries from that receipt. An unlogged batch is just handing the courier several packages at once with no such receipt — faster to hand off, but no guarantee they'll all get delivered if something goes wrong.
Key Concepts
1
What a logged batch actually gives you. Atomicity: every statement eventually applies, or none does.
Nothing more.
2
BEGIN BATCH
INSERT INTO orders_by_customer (...) VALUES (...);
INSERT INTO orders_by_product (...) VALUES (...);
INSERT INTO orders_by_day (...) VALUES (...);
APPLY BATCH;3
That is the correct use: the three denormalized copies of one order land together or not at all. Exactly
the problem query-first modelling creates.
4
What it does not give you. No isolation — another reader can see the first write before the third
lands. No rollback. No "the whole thing failed, nothing happened" in the SQL sense.
5
How it is paid for. Before running anything, the coordinator writes the batch to a batchlog on two
other nodes. Only then does it execute the statements, and it deletes the batchlog afterwards.
6
So a three-statement logged batch is roughly two extra writes plus the three real ones. If the coordinator
dies midway, another node replays the batchlog and finishes the job — which is where the guarantee comes
from, and what it costs.
7
Why batching unrelated writes makes things slower. This is the anti-pattern:
8
BEGIN BATCH
... 500 inserts for 500 different partitions ...
APPLY BATCH;9
One coordinator now writes a large batchlog, then fans out to replicas across the whole cluster and waits
for all of them. The batch is as slow as its slowest replica, and that one node is doing work that 500
parallel writes would have spread out.
10
Five hundred separate asynchronous writes go to their own replicas in parallel and finish sooner. The batch
made it worse while looking like an optimisation.
11
Unlogged batches. No batchlog, no atomicity, just several statements in one message.
12
These are worth using in one case: all statements share the same partition key. Then it is a single write
to a single set of replicas, and it is genuinely cheaper than sending them separately. Cassandra warns you
when an unlogged batch spans multiple partitions, because that is the misuse.
13
The rule. Same partition — batch away, it is one write. Different partitions but they must land
together — logged batch, and accept the cost. Different partitions and independent — do not batch, send
them concurrently.
14
What the interviewer is probing.1. "What is a logged batch for?" Probing: the purpose. Stalls: "Performance." Moves up:
atomicity across tables — all statements eventually apply or none do; it is not for throughput.
15
2. "Why can a batch make performance worse?" Probing: the misconception. Stalls: "It
cannot." Moves up: a multi-partition batch makes one coordinator responsible for many nodes, which
is slower than issuing parallel writes.
16
3. "When is a batch genuinely good for performance?" Probing: the exception. Stalls:
"Always." Moves up: when every statement targets the same partition, where it becomes a single
write.
17
4. "What does a logged batch not give you?" Probing: precision. Stalls: "Nothing." *Moves
up:* isolation — other readers can see partial results — so it is atomic but not isolated.