Repository navigation
[FEATURE]: Project-scoped stores — split the global session DB into a system DB + per-project DBs #47429
Description
Feature hasn't been suggested before.
- I have verified this feature I'm about to request hasn't been suggested before.
Describe the enhancement you want to request
I'd like to suggest splitting the single global session DB into a small system DB plus one DB per project — system DB for accounts/credentials/migrations plus a session catalog, per-project DBs for session/message/part/event and the rest. The goal: keep opencode fast under heavy parallel use across many projects over months. Full write-up with measurements: https://gist.github.com/aschokinatgmail/9859bf951129a1f64cf1cbd3f9ad300b
Why I'm asking. My daily driver (4-core/32GB laptop) ran opencode for 5 months with heavy multi-project use. The DB grew to 34 GB and the whole machine crawled: SELECT COUNT(*) FROM part took 26.7 s (0.02 s after cleanup), kernel sys-time ~41.5%, load average 25–62. Hand-pruning it to 2.1 GB dropped load to 1.8. I did that pruning manually with the sqlite3 CLI because nothing in opencode maintains storage today (#41175 shows other users doing the same by hand).
What's new here vs. the existing threads (#47223, #33356, #41175, #16101 — which I support; my numbers confirm the journal-growth diagnosis: 14.5 GB of 17 GB was the event journal): those fix growth within the one big DB. This is a different, complementary layer — scoping. Today one WAL means one global writer, so a heavy project blocks writes in every other project; one runaway project (one of mine held 52% of the DB) taxes everyone's latency; and a single file forces one retention policy on all projects. Splitting scopes each project's writes, blast radius, and retention to its own DB — and stays valuable even after the journal fixes land.
Suggested properties (details up to maintainers): stable project ID created once and stored in the project (not a path hash — survives renames/moves/worktrees); catalog as a derived, rebuildable cache; central data dir by default ($XDG_DATA_HOME/opencode/projects/<id>/). Migration should be lazy and opt-in — new sessions go to per-project DBs, the legacy global DB stays a read-only archive (my 34 GB VACUUM needed exclusive access for minutes — don't force that on first run).
Acceptance criteria, adoption path, and risks (concurrent-writer benchmarks for both SQLite drivers, fd limits for serve mode, cross-project parent_id sessions) are in the gist.
Related: #47223 #33356 #41175 #16101 #47022 #46833 #42748 #31526
Activity
github-actions commentedon Sep 5, 2026
This issue doesn't fully meet our contributing guidelines.
What needs to be fixed:
[FEATURE]:, and the required verification checkbox (confirming the feature hasn't been suggested before) must be included.Please edit this issue to address the above within 2 hours, or it will be automatically closed.
This issue might be a duplicate of existing issues. Please check:
eventtable: opencode.db reaches 13GB+, mostlymessage.updated.1snapshots (no retention/compaction) #33356: Unboundedeventtable growth reaching 13 GB+ — same mechanism, overlapping proposed fixesThe project-scoped storage split you're proposing may be genuinely new, but given the significant overlap with the above issues, please confirm it isn't better addressed as a comment or linked proposal on one of those threads.
If you believe this was flagged incorrectly, please let a maintainer know.
[-]Storage: project-scoped stores (system DB + per-project session DBs) for intensive multi-project usage[/-][+][FEATURE]: Project-scoped stores — split the global session DB into a system DB + per-project DBs[/+]github-actions commentedon Sep 5, 2026
Thank you for updating the issue! Everything looks good now — the feature request is well-structured, includes real measurements and context, and clearly explains the motivation. We appreciate the detailed write-up!
opencodejr commentedon Oct 28, 2026
Thanks for the detailed proposal and the measurements in the gist!
To restate the request: split the single global session database into a small system DB (accounts, credentials, migrations, session catalog) plus one DB per project for sessions, messages, parts and events. Each project's writes, slowdowns and retention would then stay in its own database, and existing data would move over lazily and only if you opt in. Maintainers will consider it.
Related issues, for reference:
eventtable: opencode.db reaches 13GB+, mostlymessage.updated.1snapshots (no retention/compaction) #33356: theeventtable grows without limit (open). This is the in-DB growth you describe as complementary.This needs changes to OpenCode's core storage layer, so it can't be done as a plugin.