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

[takswatiii]

Description

OpenCode Desktop’s local database grew to approximately 72 GB after roughly two weeks of use, consuming a significant portion of my Mac’s storage.

I investigated the database because macOS was suddenly running very low on disk space. The database breakdown was approximately:

• opencode.db: ~72.1 GB allocated
• Database payload: ~67.1 GiB
• event table: ~64.3 GiB
• message table: ~2.38 GiB
• part table: ~0.44 GiB
• event therefore accounted for roughly 95.8% of the measured database payload

The event data appeared to contain extremely large/repeated message and part update payloads, including message.updated.1 / message.part.updated.1 data.

I am a heavy OpenCode user, but ~72 GB of local database growth in around two weeks seems abnormal and effectively caused OpenCode to fill my disk.

There appears to be no effective retention/compaction mechanism preventing this data from growing indefinitely.

Ideally OpenCode should prune/compact redundant historical event data or provide a configurable retention/storage limit.

Possibly related to #33356.

Plugins

No response

OpenCode version

1.18.18

Steps to reproduce

1. Use OpenCode Desktop heavily across multiple coding sessions/projects over an extended period.
2. Allow normal agent activity, tool calls and long conversations to accumulate.
3. Monitor the size of the local opencode.db.
4. Inspect the SQLite database tables.
5. Observe that the event table grows disproportionately and can consume tens of gigabytes without an apparent retention limit.

In my case, after roughly two weeks, opencode.db reached ~72.1 GB, with ~64.3 GiB attributable to the event table.

Screenshot and/or share link

No response

Operating System

macOS 26.5.1 (Apple Silicon)

Terminal

Terminal.app

[github-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

[Yuepixel]

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.