SQLite performance slowed by memory lock contention

Troubleshooting
, , , ,
1

Adapted community discussion: Paraphrased and condensed from an anonymized public OpenClaw Discord support conversation from September 2026. Technical guidance was reviewed for OpenClaw 2026.9.3.

SQLite disk performance has become the limiting factor for my OpenClaw deployment. Can I switch the session store to another database backend, or is there a software fix for slow transactions and lock contention?

2

There is no supported Postgres or Redis switch for the core session and transcript store. First identify which SQLite file and subsystem are slow:

openclaw --version
openclaw gateway status --deep
openclaw status --all
openclaw memory status --deep --agent AGENT_ID

Keep the OpenClaw state directory on local SSD or NVMe storage. Avoid network filesystems and slow overlay storage. Do not delete SQLite sidecars or tune PRAGMAs by hand. If the pressure is old session volume, preview supported maintenance with openclaw sessions cleanup --all-agents --dry-run. A replaceable memory engine does not replace the core session database.

3

The detailed output shows slow SQLite transaction holds and lock waits. openclaw memory status --fix eventually times out waiting for a memory-core workspace lock. I also noticed that the CLI and Gateway may be on different versions.

4

That narrows it to memory maintenance contention rather than proof that the core database needs another backend. First align the CLI and Gateway versions. Then confirm that only one Gateway or container owns the state directory and that no concurrent memory repair, index, backup, or maintenance process is holding the lock.

Keep that state volume on local storage. If Dreaming or another memory task is active, stop competing work for a short maintenance window. Preserve the database and every -wal, -shm, and -journal file. A stale memory lock can be repaired through the supported memory command, but only after the competing owner is gone.

5

Only one Gateway uses the state directory, but it serves three agents. I would like to keep the Dreaming feature enabled. What exactly should I do during that short maintenance window?

6

It means temporarily removing competing writers, not deleting state.

  1. Create and verify an OpenClaw backup to an existing backup directory.
  2. Stop the one canonical Gateway cleanly so none of the three agents can start another memory task.
  3. Run the memory repair once for the affected agent against the same state directory and software version.
  4. Start the Gateway and inspect memory status again.
openclaw backup create --output EXISTING_BACKUP_DIRECTORY --verify
openclaw gateway stop
openclaw memory status --fix --agent AGENT_ID
openclaw gateway start
openclaw memory status --deep --agent AGENT_ID

For a container deployment, use the equivalent stop, one-off CLI, and start commands for the exact services and volume. If the repair still times out while the Gateway is definitely stopped, keep the backup, preserve all SQLite sidecars, and treat it as a persistent-state or version-specific defect rather than repeatedly forcing repair.