OpenCode database grew to ~72 GB in roughly two weeks of normal use #47022

Activity

1. github-actions

   assigned

   neriousy

   on Sep 3, 2026
2. github-actions commented on Sep 3, 2026

   

   github-actionsBot

   on Sep 3, 2026 – with GitHub Actions

   Contributor

   More actions

   This issue might be a duplicate of existing issues. Please check:

   • Unbounded growth of the event table: opencode.db reaches 13GB+, mostly message.updated.1 snapshots (no retention/compaction) #33356: Unbounded growth of the event table: opencode.db reaches 13GB+, mostly message.updated.1 snapshots (no retention/compaction) — the primary tracking issue for this problem (which you already referenced)
   • opencode.db grows to ~9 GB due to enormous message.updated.1 event snapshots #46833: opencode.db grows to ~9 GB due to enormous message.updated.1 event snapshots — same root cause, similar scale
   • OOM and ~30 GB database: huge workspace-file diffs embedded in message summaries are re-serialized in full on every message.updated event #43551: OOM and ~30 GB database: huge workspace-file diffs embedded in message summaries are re-serialized in full on every message.updated event — related unbounded growth via the same event table
   • Excessive storage: event table stores full message snapshots per streaming update — community tool available #41175: Excessive storage: event table stores full message snapshots per streaming update — same underlying issue with community tooling noted
   • SQLite auto_vacuum is disabled, database files grow indefinitely #31526: SQLite auto_vacuum is disabled, database files grow indefinitely — related storage hygiene issue
3. Yuepixel commented on Sep 10, 2026

   

   Yuepixel

   on Sep 10, 2026

   More actions

   Adding data from a normal single-user Windows install (opencode desktop 1.18.30) that matches this pattern. Not a power-user/huge setup.

   Database size breakdown (opencode.db):

   • Total DB: ~2.36 GB
   • event table alone: ~2.03 GB (149,137 rows)

   Rows / bytes by event type:

   type	rows	size
   message.updated.1	37,664	~1,487 MB
   message.part.updated.1	99,943	~538 MB
   session.updated.1	11,318	~6 MB
   message.removed.1	119	~0.01 MB
   session.created.1	95	~0.04 MB

   Key observations:

   • Orphaned events = 0. Every event's aggregate_id still exists in session, so a prune that only removes orphaned events (as proposed in feat(opencode): add db stats, prune, and vacuum CLI commands #43456) would reclaim nothing here. The growth is live-session historical snapshots, not orphans.
   • A single session dominates: one session accounts for ~1,309 MB across 2,126 events (~616 KB/event average) — a handful of very large snapshots drive most of the size.
   • The event table has no timestamp column, so time-based retention is not possible without a schema change; only superseding-snapshot compaction (keep the newest snapshot per aggregate, drop superseded ones) helps.

   This is consistent with the "full message snapshots stored on every streaming update with no retention" root cause, and confirms ~2 GB is reachable in ordinary use, not just the 13–51 GB reports.

   Separately (context, not DB size): long sessions also get slow because the full history is resent each turn; compaction.prune defaults to false. Setting it to true mitigates the slowdown.
4. thdxr commented on Oct 11, 2026

   

   thdxr

   on Oct 11, 2026

   Member

   More actions

   Thanks for the report! OpenCode 2.0 is now out and development is focused on V2, so we're closing issues filed against OpenCode 1. Please upgrade (opencode upgrade --major, details: https://anoma.ly/notes/opencode-2-0), and if this is still relevant on 2.0, reopen this issue or open a new one with your 2.0 version.

   — from 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊
5. thdxr

   closed this as not plannedon Oct 11, 2026