Repository navigation
statev2.sqlite grows without bound: orchestration_events is 33 GB on one laptop #29434
Description
What I see
On a MacBook Pro running T3 Code T3 Code (Nightly).app on macOS 27.0.1, ~/.t3/userdata/statev2.sqlite is 63 GB (16,444,835 pages of 4096 bytes, freelist 0, so it is not reclaimable free pages). A read-only dbstat query shows where the space is:
| Table or index | MiB |
|---|---|
| orchestration_events | 33,359 |
| orchestration_v2_projection_turn_items | 18,387 |
| orchestration_v2_projection_nodes | 3,518 |
| sqlite_autoindex_orchestration_events_1 | 1,841 |
| idx_orch_events_stream_sequence | 795 |
| idx_orch_events_stream_version | 788 |
| idx_orchestration_events_agent_stream_sequence | 749 |
| orchestration_v2_projection_messages | 487 |
This machine runs many delegated agent threads per day, so the event stream grows by several GB a week and nothing compacts it. The database is also a single file, so Time Machine re-copies it on every change.
Ask
A retention or compaction mechanism for orchestration_events and the derived projections, for example: keep events only for the last N days or for open threads once the projections are materialised, a maintenance command that prunes events for settled threads and runs VACUUM, or a setting that caps the event log. If the events are needed for replay, a per-thread archive file would still keep the live database small.
Happy to provide more measurements or test a build.
Activity
juliusmarminge commentedon Nov 2, 2026
Duplicate of #28903. That issue reports the same thing:
statev2.sqlitegrows without bound,orchestration_eventsandorchestration_v2_projection_turn_itemstake most of the space, andfreelist_countis 0. It asks for the same retention, prune and compaction mechanism. Please add your measurements there (63 GB on macOS Nightly, with thedbstatbreakdown) so that the discussion stays in one place.For reference, current main (
edc37c96c8) already removes superseded snapshots for messages, nodes and turn items fromorchestration_eventsevery six hours, and it reclaims free pages on databases that use incremental auto_vacuum. Main has no retention or archiving for settled threads yet; that is what #28903 tracks.