Consolidated Database
RaiSE stores all personal state in a single SQLite database at ~/.rai/raise.db. This is the consolidated database — one file that holds sessions, patterns, missions, worktrees, signals, and learning records across all your projects.
What It Stores¶
| Table | Content |
|---|---|
sessions |
Session records — start time, end time, project, summary, type |
patterns |
Extracted learnings — content, context keywords, scope, source story |
missions |
Mission definitions — name, objectives, status, lifecycle timestamps |
worktrees |
Registered worktrees — path, branch, mission binding, env file state |
signals |
Work events — epic/story start, complete, blocked, with timestamps |
learning_records |
Calibration data — estimated vs actual durations per story |
The database is personal — it is not committed to git. It lives in your home directory and persists across projects, worktrees, and sessions.
Migration from Per-Project DBs¶
Prior to v3.1.0 (Epic E8204), RaiSE maintained a separate .raise/raise.db in each project directory. This caused state fragmentation: patterns captured in one worktree were invisible in another, and mission state could diverge between checkouts.
E8204 consolidated all personal state into ~/.rai/raise.db. Per-project databases are no longer created. The rai db consolidate command migrates existing per-project data into the global store.
If you have old per-project databases, run:
Key Commands¶
| Command | What it does |
|---|---|
rai db status |
Show database location, size, and table row counts |
rai db check |
Validate schema integrity and detect corruption |
rai db consolidate |
Migrate a per-project DB into the global store |
rai db export |
Export the full database to a portable JSONL backup |
The Golden Rule: Never Touch .db Files Directly¶
Do not open, edit, copy, or move .raise/*.db or ~/.rai/raise.db with anything other than the rai CLI.
SQLite files can be silently corrupted by concurrent writers. Copying a live database can produce an inconsistent snapshot. Editing records directly bypasses validation and can leave foreign keys broken.
The CLI is the only safe interface. If you need to inspect data for debugging, use rai db export to get a JSONL snapshot, or rai db status for counts.
Backup and Recovery¶
The database is not version-controlled. Back it up as part of your machine backup strategy. For point-in-time recovery:
If the database becomes corrupted:
The rebuild command uses the archived JSONL event logs (stored in .raise/sync/) to reconstruct the database state. Some learning data may be lost if archives are incomplete.
Next Steps¶
- CLI Reference: db — all flags and options
- Memory — how patterns and sessions relate to database records
- Worktrees — worktree registrations stored in the DB
- Missions — mission state stored in the DB