Memory and State Management
State Checkpointing — Stack
State checkpointing › Stack
Technology landscape as of 2026-10-10. Knowledge cutoff May 2026.
Selection criteria
You are choosing a serialisation and storage mechanism for run state whose value is realised exactly once, in an abnormal situation, possibly months after it was written.
- Write cost at the chosen frequency. Snapshot cost multiplies by the number of boundaries; what is negligible once per run is prohibitive once per step.
- Schema evolution. Whether a snapshot written by an older build can be loaded by a newer one, and whether the mechanism gives you a version to branch on.
- Determinism requirements. Whether the mechanism restores by replaying recorded history, which constrains how the surrounding code may change, or by loading a state value.
- Side-effect bookkeeping. Whether completed external calls are represented natively so that resume does not repeat them, or whether that is yours to build.
- Snapshot size and payload handling. Whether large values can be stored by reference without making restore depend on a store with a different lifetime.
- Restore testing surface. Whether it is practical to load an arbitrary historical snapshot in a test, which is the only way the mechanism is ever known to work.
- Retention and erasure. Whether snapshots can be enumerated, aged out, and purged per subject, since they are a full copy of whatever the run touched.
Options
| Option | Best for | Watch out for |
|---|---|---|
| Durable execution engine with automatic state capture (Temporal, Restate, Azure Durable Functions, AWS Step Functions) | Long runs that must survive process loss and resume exactly, with side-effect bookkeeping included | Replay determinism constrains ordinary code changes; versioning in-flight workflows is a discipline the whole team must learn |
| Graph-framework checkpointer per thread (LangGraph checkpointers over Postgres, SQLite, or Redis) | Agent runtimes where the state object is already explicit and typed | Snapshot schema is your state schema; changing it strands in-flight threads unless migration is planned |
| Explicit serialised state in a database row, written at chosen boundaries | Full control over what is captured and when, with ordinary queries over snapshots | Everything is yours to build, including versioning, side-effect records, and retention |
| Event sourcing: replay the run's events to rebuild state (Kafka, EventStoreDB, an append-only table) | Runs that must be auditable and reconstructible to any point, not just the last one | Replay cost grows with run length; per-subject erasure against the event log must be designed in advance |
| Object storage for large snapshot payloads with a small index row (S3, GCS, Azure Blob) | Runs whose state contains large artefacts that would bloat a database | Two lifetimes to reconcile; a lifecycle rule that removes payloads leaves index rows that cannot be restored |
| Process or container memory snapshots (CRIU, VM or microVM snapshots, Firecracker) | Restoring an exact execution environment including in-flight native state | Opaque to inspection, tightly coupled to the runtime version, and unable to represent side effects as a concept |
| Vendor-managed session or run state in a hosted agent platform | Getting resumability without building any of it | Retention window, size limits, and restore semantics are the vendor's; verify erasure reaches snapshots before trusting it with real data |