Persistence and the .usearch file

A memista partition is two files on disk. That’s the whole persistence story, and it’s deliberate — you can inspect, copy, and reason about it with standard tools.

The two files

• SQLite database (WAL mode) — holds the chunks_<database_id> table with each chunk’s text and metadata. Open it in sqlite3 and run queries against it directly.
• <database_id>.usearch — the USearch index for that partition, saved to disk after each insert batch.

Isolation is by name

Each database_id gets its own SQLite table and its own .usearch file. Partitions don’t share an index. Dropping a partition (DELETE /v1/drop) removes both.

Backups are boring

# checkpoint the WAL, then copy both files
sqlite3 my_app.db 'PRAGMA wal_checkpoint(TRUNCATE);'
cp my_app.db my_app.usearch /backups/

Because nothing is opaque, debugging a wrong result means opening the data — not filing a ticket. This is why memista suits edge and local-AI workloads. See how it works for how insert and search keep the two files in sync.