Skip to content

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:

rai db consolidate --project /path/to/project

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:

rai db export --output ~/rai-backup-$(date +%Y%m%d).jsonl

If the database becomes corrupted:

rai db check       # diagnose
rai db rebuild     # reconstruct from signal/session JSONL archives

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