In Flink, what is the difference between a checkpoint and a savepoint?

## Same machinery, different contract Both a checkpoint and a savepoint are produced by the barrier-based snapshot algorithm, and both capture the same two things: every operator's state and every source's read position. If you only look at the algorithm, they are the same object. The difference is the contract around it — who triggers it, who owns it, what format it is written in, and what you are allowed to do with it afterwards. ## Checkpoints: the system's business A checkpoint exists so that the job can recover from its own failures without human involvement. - **Triggered by Flink** on the configured interval. - **Optimised for frequency.** With an incremental-capable state backend a checkpoint can upload only the state files that changed since the previous one, which makes large state affordable to snapshot often. The format is whatever that backend finds cheapest. - **Owned by the job.** Flink retains a bounded number of completed checkpoints and deletes older ones. When the job is cancelled the checkpoint data goes with it, unless you asked for externalized retention (`execution.checkpointing.externalized-checkpoint-retention: RETAIN_ON_CANCELLATION`; the default is `NO_EXTERNALIZED_CHECKPOINTS`), in which case it survives and *you* become responsible for deleting it. - **Restored automatically** on failover, with no operator action. ## Savepoints: your business A savepoint exists so that a human can do something deliberate to a job. - **Triggered explicitly**, by CLI, REST or the client API. - **Always self-contained.** It never references files belonging to an earlier snapshot, so you can copy or move the directory and it still restores. - **Canonical format by default** — a unified, backend-independent layout, which is what lets you restore a savepoint taken with one state backend into a job using a different one, and what gives the best chance of restoring across Flink versions — though Flink 2.0 does not guarantee state compatibility with 1.x snapshots at all. Writing it costs more than a checkpoint, because incremental tricks and backend-native layouts are given up for portability. A *native*-format savepoint is available when you want a faster write and do not need to switch backends. - **Always aligned.** A savepoint never uses unaligned mode, even on a job with unaligned checkpoints enabled. - **Never deleted by Flink.** The lifecycle is entirely yours. ## The operations savepoints exist for The classic four: 1. **Job upgrade.** Stop with a savepoint, deploy a new jar, restore. State survives the code change as long as the operators that own it can still be identified — which is why setting stable operator UIDs with `uid("...")` on every stateful operator is the single most important habit for an upgradeable Flink job. 2. **Rescaling.** Restore at a different parallelism; keyed state is redistributed by key group, which is why the maximum parallelism is fixed at first run and cannot be changed by a savepoint. 3. **Migration.** Move a job to another cluster, another region, or another Flink version. 4. **A/B or blue-green.** Start a second job from the same savepoint and compare, since a self-contained savepoint can be restored more than once. ## Doing it safely ```bash # take a savepoint and stop the job in one atomic operation bin/flink stop --savepointPath s3://state/savepoints <jobId> # resume the new build from it bin/flink run -s s3://state/savepoints/savepoint-abc123 target/job.jar ``` Stopping *with* a savepoint is better than cancel-then-savepoint: it stops the sources, takes the snapshot and terminates as one step, so no records are processed after the snapshot and any transactional sink commits cleanly instead of leaving an open transaction behind. The separate `--drain` flag additionally emits a final `MAX_WATERMARK` to flush event-time windows; use it only when the job will not be resumed. ## The overlap people get wrong Two things blur the line and cause confusion in interviews. First, a **retained checkpoint can be resumed from manually** with the same `-s` flag as a savepoint. So "you can only resume from savepoints" is wrong, and Flink's own compatibility table goes further: an aligned checkpoint supports changed job code, rescaling and a Flink minor-version upgrade. What you give up is ownership and portability. A checkpoint cannot switch the state backend, is not self-contained or relocatable (an incremental one references files from earlier checkpoints), and an *unaligned* checkpoint supports neither arbitrary job changes nor a minor-version upgrade. Second, because the job owns its checkpoints, the one you meant to upgrade from may already be gone — subsumed by a newer checkpoint, or deleted on cancellation because retention was never enabled. Treating a retained checkpoint as your upgrade path works right up until the day you change a backend, move the files, or find the checkpoint was unaligned, and then it does not. ## Choosing in practice Run checkpointing continuously with an interval matched to how much replay you can tolerate, and enable retention so a crashed-and-cancelled job leaves something behind. Take a savepoint before every deliberate change — deploy, rescale, migration — and keep it until the new version has proved itself, because it is your rollback.