Batch vs Stream Processing
Batch processing handles bounded data on a schedule; stream processing handles unbounded data continuously as it arrives.
Bounded versus unbounded
The deepest distinction is whether the data is bounded or unbounded. Batch processing operates on a finite, complete dataset: read it all, compute, write results, finish. Stream processing operates on data that never ends: it processes each record or small window as it arrives and never has the whole dataset in hand at once.
Batch
- Works on complete, bounded datasets.
- Higher latency, results after the batch runs.
- Simpler correctness: the full input is available.
- Efficient use of resources; ideal for heavy computation.
Stream
- Works on continuous, unbounded input.
- Low latency, results within seconds or less.
- Harder correctness: late and out-of-order data must be handled.
- Ideal for monitoring, alerting, and live views.
The unifying view
Batch can be seen as a special case of streaming over a bounded window, and modern frameworks increasingly express both with one model. This lets the same logic run as a low-latency stream and as a batch backfill over history, reducing the risk that the two paths compute different answers.
Choosing
Use streaming when the value of a result decays fast, live dashboards, anomaly alerts. Use batch when completeness and heavy computation matter more than latency, the authoritative analysis and the published record. Many systems run both: a stream for immediate feedback and a batch pass for the definitive result, as in the real-time versus archival split. For a fusion program, live pulse monitoring is streaming while the calibrated, deposited analysis is batch.