Unbounded growth of the `event` table: opencode.db reaches 13GB+, mostly `message.updated.1` snapshots (no retention/compaction)

[rustyaos]

Summary

The local SQLite store (~/.local/share/opencode/opencode.db) grows unbounded on long-lived instances because the event-sourcing event table is never pruned, capped, or compacted. On two of our long-running instances it reached ~13 GB each, filling a 22 GB volume to 97–99% and eventually producing sqlite3.OperationalError: database or disk is full on ordinary queries — the instance becomes effectively unusable.

The actual conversation data is tiny by comparison; >90% of the DB is the event log, and within it a single event type (message.updated.1) dominates.

Measured breakdown (real instance, 13.7 GB DB)

page_size=4096  page_count=3342166  total=13.69 GB
freelist_count=18  dead=0.00 GB (0.0%)        <- live data, VACUUM does not help

Per-table (sum(length(data))):

table	rows	size	avg/row
event	141,951	12.20 GB	83.9 KB
message	6,955	1.15 GB	161 KB
part	27,775	0.07 GB	2.4 KB
others	—	~0	—

Within event, by type:

event type	rows	size	avg
message.updated.1	26,463	11.94 GB	440 KB
session.next.tool.success.1	7,843	0.12 GB	14.8 KB
message.part.updated.1	52,644	0.10 GB	1.8 KB
everything else	~55k	< 0.3 GB	—

So ~87% of the entire database is message.updated.1 events. With ~6,955 messages there are ~3.8 message.updated events per message, each persisting what looks like a full message snapshot (avg 440 KB), and all historical snapshots are retained forever.

The same pattern was observed independently on a second instance (also ~13 GB, same event-table dominance), so this is reproducible, not a one-off.

Root cause (confirmed in source, dev branch)

packages/core/src/event/sql.ts — the event table has no TTL, no row cap, no size limit, and no compaction column; it just stores every event's full data JSON:

export const EventTable = sqliteTable("event", {
  id: text().$type<EventV2.ID>().primaryKey(),
  aggregate_id: text().notNull().references(() => EventSequenceTable.aggregate_id, { onDelete: "cascade" }),
  seq: integer().notNull(),
  type: text().notNull(),
  data: text({ mode: "json" }).$type<Record<string, unknown>>().notNull(),
}, ...)

packages/core/src/event.ts — the only delete against event is a full-aggregate cascade, used when an entire session/aggregate is removed:

function remove(aggregateID: string) {
  return db.transaction(() => Effect.gen(function* () {
    yield* db.delete(EventSequenceTable).where(eq(EventSequenceTable.aggregate_id, aggregateID)).run()
    yield* db.delete(EventTable).where(eq(EventTable.aggregate_id, aggregateID)).run()
  })).pipe(Effect.orDie)
}

There is no partial pruning — nothing collapses superseded message.updated.* snapshots, keeps only the latest per message, caps per-aggregate history, or stores deltas. packages/opencode/src/sync/README.md confirms this is an intentional append-only log "for session replayability." That's a reasonable design goal, but with full-snapshot message.updated events and no retention it means every session's event history accumulates for the lifetime of the session, with no upper bound.

SessionCompaction.prune does not address this — it trims context tokens sent to the model, not persisted event rows.

Impact

• Disk exhaustion on long-lived instances (containers/sandboxes/servers with persistent home dirs).
• Once the volume is full, even read queries that need temp space fail with database or disk is full.
• VACUUM cannot reclaim it (freelist ≈ 0%; it is all live data). The only current remediation is deleting whole sessions (cascade) or manually DELETE FROM event ....

Suggested fixes (any one would help)

1. Compact superseded snapshots: for snapshot-style events like message.updated.*, retain only the latest event per (aggregate_id, message_id) (or per message seq), deleting older ones — newer fully supersedes older.
2. Store deltas instead of full snapshots for message.updated (the README already notes session.updated was moved to fields-only; message.updated appears to still carry a full snapshot).
3. Per-aggregate retention cap / periodic compaction of the event log for inactive/completed sessions.

Environment

• Observed on builds in the 1.15.x–1.17.x range; root cause confirmed present on dev (current latest, 1.17.9) via the source above.
• SQLite store at ~/.local/share/opencode/opencode.db.

Happy to provide the full per-session breakdown or a repro script if useful.

[github-actions]

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

• event table bloat from message.updated.1 causes OOM when loading old sessions #32005: Same root cause — message.updated.1 events accumulating in the event table causing the database to grow unboundedly. That issue focuses on OOM when loading old sessions; this one focuses on disk exhaustion at a larger scale (13 GB), but both trace back to the same full-snapshot-per-streaming-update design and lack of compaction/pruning for historical events.
• SQLite auto_vacuum is disabled, database files grow indefinitely #31526: Related but distinct — about SQLite auto_vacuum being disabled so deleted rows don't reclaim disk space. Different root cause (reclaiming freed pages vs. live data never being deleted), but same overall symptom of unbounded disk growth.

If your issue is primarily about the message.updated.1 snapshot accumulation, #32005 is the closest match and combining discussion there may be useful.

[joaomj]

Same issue here. After a few months of regular use, ~/.local/share/opencode was consuming over 50 GB split roughly 45 GB in tool output artifacts and 5.7 GB in the SQLite database (opencode.db). There is no built-in mechanism to cap or prune either, and neither compaction.prune nor tool_output.max_lines/bytes addresses persisted storage, only in-context token limits.

As noted in the original issue, the event table grows unbounded with full-snapshot message.updated events that are never compacted. Combined with tool outputs saved to disk for every turn, this makes long-term usage on storage-constrained machines (laptops, containers, VPS) untenable without manual intervention or third-party tools like ocgc.

A configurable retention policy (max DB age, max size cap, or auto-compaction of superseded events) would be extremely valuable.

[pspranger-throw]

Adding to that:

Reproduction (one command → ~2.3 GB of events)

A single bash tool call downloading a model file:
wget -q --show-progress "https://huggingface.co/<...>/model.Q4_K_M.gguf" -O model.gguf 2>&1

• Downloaded file: 1.8 GB
• --show-progress redraws the progress bar in place via \r many times per second
• OpenCode captures the stream and emits a message.part.updated.1 event containing a full snapshot of the accumulated output on every redraw

Result for that one part: 79,083 events, 2,325 MB — 97.7% of the session's event cost and ~75% of an 3.1 GB opencode.db. The part's actual final content was 81 KB, so the overhead here was ~29,000×.

Environment: OpenCode 1.17.18, Linux terminal, SQLite WAL mode, auto_vacuum=0.

Where the bytes actually are

For the affected session, the event table was 84% of the DB. Within it:

event type rows total size avg
message.part.updated.1 178,062 2,470 MB 14.5 KB
message.updated.1 36,939 16 MB 456 B
session.updated.1 6,874 3.8 MB 573 B

So in our case the dominant type was message.part.updated.1 (part-level streaming snapshots), ~154× more costly by bytes than message.updated.1. One single part held 2,325 MB of the 2,380 MB total — the bloat is extremely concentrated, not spread across many sessions.

The waste is byte-identical consecutive snapshots

Growth of that one part across its 79,083 updates:
update # part size
1st 322 B
1,000th 31,017 B
10,000th 31,017 B
40,000th 31,017 B
79,083rd (last) 83,352 B

From update ~1,000 to 40,000 the part content was byte-for-byte identical (the progress bar at full size, unchanged).

OpenCode re-snapshotted the same 31 KB 39,000 times — ~1.2 GB of pure duplicates that carry zero information.

Any command that emits thousands of output lines triggers this: wget --show-progress, tail -f, verbose build logs, yes/loops, etc.

[EgilSandfeld]

Confirmed on Windows x64 with OpenCode v1.17.18.

opencode.db reached 10.69 GB:

• event table: 8.13 GB allocated / 7.15 GiB JSON
• message.part.updated.1: 280,318 rows / 4.55 GiB
• message.updated.1: 62,397 rows / 2.60 GiB
• Largest active session: 38,592 events / 2.13 GiB
• Largest individual event JSON: 248.7 MiB

Tool breakdown exposed the write amplification clearly:

• bash: 125,685 snapshots / 3.67 GiB
• A single bash tool part: 2,001 snapshots / 189.6 MiB
• A completed apply_patch event: 248.7 MiB

PRAGMA freelist_count is 0, so this is live append-only data—not reclaimable SQLite/VACUUM bloat.

Active sessions already account for 2.96 GiB and sessions archived less than one day for another 2.67 GiB. Session retention therefore cannot prevent this; intermediate tool/message updates need deltas or terminal checkpoints instead of repeated full durable snapshots.

[chubes4]

Revised safety model in #36710: compaction is explicit and dry-run by default, limited to 1,000 rows per transaction, and validates the current message/part projection against the retained latest snapshot. The sync protocol has no checkpoint-marker version negotiation, so apply is allowed only for aggregates with no workspace or sync owner; synced/owned aggregates remain report-only pending a protocol compatibility decision.

The supplied production measurement of message.part.updated.1 is 2,614,320 rows / 17.73 GB (within a 20.07 GB event table), which is the primary target for bounded remediation.