Excessive storage: event table stores full message snapshots per streaming update — community tool available

Problem

opencode.db grows to multiple gigabytes because the event table stores a complete copy of every message on each streaming update — not a delta. On a typical installation with heavy agent use, the event table accounts for ~90% of the database size.

My installation (macOS, ~weeks of daily use):

The message.updated.1 events are on average 4.4× larger than the final messages themselves, because each event carries the full accumulated text at that point in the stream.

Root cause

While a reply streams in, the event log records the full state on every token batch. For a 35 KB final message, the event table may store 20+ intermediate snapshots, each increasingly large. This is the expected behavior of an event-sourced architecture, but without compaction or pruning, it becomes a storage problem.

Proposed fix (upstream)

1. Don't persist full snapshots per streaming update — store deltas or only the final state.
2. Prune the event feed when a session completes — once streaming is done, intermediate snapshots serve no purpose.
3. Add a built-in opencode db prune command — similar to git gc, let users reclaim space safely.

Community tool available

I built a single-file Python script (stdlib only, no dependencies) that safely reclaims this space without deleting any sessions, messages, or file parts:

https://github.com/ANGELBERRIOS23/opencode-db-prune

Features:

• Report-only mode by default (changes nothing without --apply)
• Backs up before pruning
• Runs PRAGMA integrity_check before and after
• Refuses to run if the DB is open or already corrupt
• Verifies message content is readable outside event before deleting
• Enables auto_vacuum = INCREMENTAL for future reclaimability
• Cross-platform (macOS tested, Linux/Windows implemented)

On a real 39 GB installation it reclaimed 36 GB (down to 3.15 GB) with all 2,106 sessions, 59,294 messages, and 293,777 file parts intact.

I'd be happy to collaborate if the team wants to integrate this as a built-in command or adapt the approach upstream.

Related issues

• #22110 — Session storage grows unboundedly
• #31391 — why opencode.db so large?
• #16777 — High memory usage and database bloat