Comparison
Pipeline checkpointvsSavepoint
Pipeline checkpoint
the job died and came back at the position it had saved ninety seconds ago, replaying everything since without duplicating output.
A periodic consistent snapshot of a streaming job's state and input positions, taken so a failure can resume from it rather than from the beginning. Everything about a streaming job's recovery time and its delivery guarantee is set here: the interval bounds how much is re-read, and the atomicity of the snapshot with respect to output is what makes end-to-end exactly-once possible. Frequent checkpoints cost throughput; rare ones cost a long, visible catch-up after every restart.
Full entry →Savepoint
you needed to deploy a new version of the job, so you took a snapshot deliberately, stopped it, and started the new code from that snapshot.
A checkpoint taken on purpose and kept, so a job can be stopped and restarted from it — usually across a code change, a scale change or a cluster migration. It is the streaming equivalent of a deploy artefact, and the constraint it creates is real: your new code has to be able to read the old state, so operator identity and state schema become things you cannot rename casually.
Full entry →