Repository navigation
event table dominates the database: 9.03 GB of event log for 1.09 GB of message content #53760
Description
Summary
After ~8 months of use, opencode.db on this machine reached 11,370,909,696 B. Almost all of it is the append-only event table: 9,029,068,170 B of event payload against 1,093,108,053 B of actual message content in part.
It is not stale history. 68% of those events belong to sessions touched in the previous month, and sessions older than 90 days have zero events, so the growth tracks recent activity rather than accumulated age.
Environment
- opencode
1.18.32, Windows 11 - database at
~/.local/share/opencode/opencode.db - ~8 months of use, 1,075 sessions
Measurements
All taken with opencode db "<query>", before any cleanup:
| Metric | Value |
|---|---|
opencode.db file size |
11,370,909,696 B |
PRAGMA page_count × PRAGMA page_size |
2,776,101 × 4096 B |
PRAGMA freelist_count |
0 (no free pages, so VACUUM alone would not have reclaimed anything) |
SELECT COUNT(*) FROM event |
1,364,445 |
SELECT SUM(LENGTH(data)) FROM event |
9,029,068,170 B (~6.6 KB per row) |
SELECT COUNT(*) FROM part |
346,255 |
SELECT SUM(LENGTH(data)) FROM part |
1,093,108,053 B |
SELECT COUNT(DISTINCT aggregate_id) FROM event |
1,071 |
SELECT COUNT(*) FROM event_sequence |
1,071 |
SELECT COUNT(*) FROM session |
1,075 |
COUNT(DISTINCT aggregate_id) equals the event_sequence row count, and every aggregate id matches a session id (0 aggregates without a session), so the event log is one stream per session.
Distribution by session age
Bucketing sessions by last activity, with the event payload summed per session:
| Session age | Sessions | Events |
|---|---|---|
| 0–7 days | 388 | 431,487 |
| 7–30 days | 677 | 928,926 |
| 30–90 days | 6 | 4,032 |
| 90–180 days | 3 | 0 |
| >180 days | 1 | 0 |
Concentration: the heaviest single session held 1,034,594,099 B of payload in 74,738 events, and one orchestration session together with its sub-session tree accounted for 315,229 events (the parent alone held the 1.03 GB above).
Workaround (verified)
Deleting finished sessions through the CLI and compacting:
opencode session delete <session-id> # also removes the session's sub-session tree
opencode db "VACUUM"
This took the file from 11,370,909,696 B to 4,892,659,712 B — a 6,478,249,984 B reduction — and PRAGMA quick_check returns ok afterwards.
Two operational notes from doing it: VACUUM writes the whole database through the WAL, so the WAL grows to roughly the database size until it is checkpointed (and a wal_checkpoint(TRUNCATE) needs a writable connection; a read-only one reports log: 0 and changes nothing). Also, deleting a session removes its sub-session tree, so the reclaimed space can be much larger than the deleted session itself.
Questions
- Is the per-event payload duplication intentional — an event-sourced design that stores the full
partcontent in every event — or is it unexpected? - Is there a supported retention or compaction path, or a plan to store deltas/references instead of the full payload per event?
- Would a documented retention policy (for example, dropping the event log of archived sessions) be a welcome contribution?
I searched the tracker for database, sqlite, storage and size before opening this and found nothing, so apologies if it duplicates something I could not find.
Activity
opencode-agent commentedon Oct 7, 2026
Thanks for the detailed measurements and the verified cleanup steps! This looks like the same problem tracked in #33356: the
eventtable grows without limit (mostly full-snapshotmessage.updated/message.part.updatedevents), with no retention or compaction, soVACUUMalone can't reclaim the space. That issue also covers your questions about whether storing a full payload per event is intended and about adding a retention or compaction path (see the proposal discussed there, #36710). Your numbers and the delete-session +VACUUMworkaround would be useful to add there.The bot will close this issue as a duplicate in 1 day unless you reply explaining how your problem is different.
github-actions commentedon Oct 7, 2026
This issue might be a duplicate of existing issues. Please check:
eventtable, dominated by retainedmessage.updated.1snapshots, with no retention or compaction.opencode.dbgrew to about 9 GB, with most payload in largemessage.updated.1event snapshots.opencode-agent commentedon Oct 8, 2026
Closing this as a duplicate of #33356, since there's been no reply saying how it's different. Please follow that issue for unbounded
eventtable growth and any retention or compaction work. Your measurements and the delete-session +VACUUMworkaround would be a useful comment there. If your case does turn out to be different, reply here and we can reopen. Thanks for the thorough report!