Does a persistent context store guarantee recovery of Node-RED flow state after an abrupt restart?

No—a persistent context store does not guarantee recovery after an abrupt restart

Configuring a pluggable context store in settings.js moves flow and global state out of process memory, but it does not turn that state into a transactional, crash-proof record. An abrupt termination can still lose the most recent updates if the store buffers writes.

Confirmed facts vs. likely explanation

Confirmed. Node-RED's default context store is memory-resident; values are lost on a full runtime restart. When a persistent store is configured, Node-RED delegates context operations to that module, which may write to disk or an external database. A graceful shutdown typically triggers the store's close or flush path.

Likely explanation. Many persistent stores use asynchronous write-behind caching or rely on OS-level buffering. An abrupt process termination—such as SIGKILL, an unhandled crash, or power loss—can discard any update still sitting in that buffer. Whether the last write survives depends on the specific plugin's flush policy and the underlying storage layer, not on the mere presence of a persistent store.

Verifying the durability boundary

1. Configure a persistent context store in settings.js and set a known value from a function node.
2. Stop Node-RED gracefully and confirm the value is restored on restart.
3. Repeat with an immediate process termination (for example, kill -9 <pid> on Linux) and check whether the value survives.
4. If using a file-based store, remember that the operating system may still cache writes; a hard power loss can lose data that a kill -9 preserves.

The diagnostic detail that matters

Which context store module are you using (for example, a file-based store, SQLite, Redis, or another backend), and which Node-RED version? That determines whether you need to add explicit checkpointing, increase flush frequency, or accept the durability limit.