WhispAssist/docs/adr/0006-storage-sqlite.md

ADR-0006 — Storage: SQLite index + on-disk audio/transcript files

• Status: Accepted
• Date: 2026-06-30
• Context source: Design doc §"Recording Persistence and Storage", §"Crash Recovery"

Context

WA stores recordings, transcripts, notes, speakers, participants, tags, and meeting metadata locally; needs fast list/filter/search; must survive crashes; and must let users choose the base directory, set retention, and export.

Decision

• Large/opaque artifacts on the filesystem: audio (.wav/compressed) and the canonical transcript JSON live as files under the storage root, one folder per meeting.
• Index & relations in SQLite (via sqlx): meetings, speakers, participants, tags, action items, and file paths; FTS5 virtual table over transcript/notes text for full-text search (FR-SEARCH-1).
• Audio is the source of truth. Audio is flushed to disk during capture; transcript/notes are derived and regenerable. Auto-save transcript/notes at intervals; on startup, detect meetings with audio but no finalized transcript and offer recovery (FR-REL-1).

Default root: %LOCALAPPDATA%\WhispAssist with per-meeting subfolders; user-configurable base directory and retention policy (size cap / age cap) in Settings (FR-STORE-2).

Consequences

• Positive: embedded, serverless, zero-config; FTS5 covers search; files keep the DB small and make export/backup a folder copy; crash recovery is straightforward because audio persists first.
• Negative: must keep DB rows and files consistent (transactional writes + a reconcile pass on startup); retention enforcement is a background job that must respect "audio is source of truth" (never orphan a meeting's audio while its transcript is mid-generation).
• Optional at-rest encryption (NFR-SEC-3) can wrap the storage root and/or use SQLCipher; deferred to Phase 8.

Revisit if

We need multi-device sync (would change the data model and conflict story) — out of scope for the local-only product.