storage-optimizes-concurrent-access-and-search
IN derived (depth 1)
The storage layer optimizes for both concurrent access (WAL mode enables non-blocking reads during writes) and full-text search (derived FTS5 index rebuilt from scratch on every save guarantees consistency), making the persistence layer production-ready for multi-reader workloads with search capability.
Summary
The persistence layer is set up to handle real-world usage patterns well: multiple processes can read the database simultaneously without blocking writers, and search always reflects the latest data because the full-text index is completely rebuilt on each save rather than incrementally maintained. This combination means you get both concurrency and search consistency without having to choose between them.
Justifications
SL — WAL mode and derived FTS5 are independent optimizations that together enable concurrent searched access without consistency trade-offs
Antecedents (all must be IN):
- storage-uses-wal-mode — SQLite connections enable WAL mode on initialization, allowing concurrent readers without blocking writes.
- storage-fts-is-derived-index — The FTS5 full-text search index is rebuilt from scratch during every `save()`; it is a derived index, never the source of truth.
Dependents
These beliefs depend on this one:
- storage-is-fully-production-grade-across-backends — Both storage backends achieve fully production-grade operation — concurrent access optimization (WAL mode, derived FTS5 indexes), equivalent safety guarantees (atomic isolated mutations through backend-appropriate mechanisms), and multi-tenant isolation — when both backends provide complete API coverage.