One .mv2 file carries data, indexes, and history
Memvid packages content, metadata, checksums, a write-ahead log, data segments, lexical and vector indexes, a time index, and a table of contents into one file. Writes append immutable frames, while commits establish a recoverable state. Applications can search current content, inspect a timeline, or branch from an earlier state. The appeal is operational: an agent's memory can be copied or archived as a file instead of exported from a database service.
The file is still a database, with the failure modes that implies. The format reserves a 4 KB header and an embedded WAL region that can grow from 1 to 64 MB. Indexes and payload offsets must remain consistent across writes and recovery. A backup copied during the wrong moment or a damaged file can affect the whole memory set. Use the verification API, keep versioned copies, and test reopening those copies before calling portability a recovery plan.
Lexical, vector, media, and encryption features are optional
The base crate can be extended through Cargo features. lex adds Tantivy BM25 search, vec adds HNSW vectors and local ONNX text embeddings, and other flags cover PDF extraction, CLIP image embeddings, Whisper transcription, temporal parsing, parallel segments, encrypted capsules, and text cleanup. This keeps a basic build from inheriting every media dependency, while letting one file hold several retrieval modes.
Local vector search is not automatic after adding the feature. The README instructs users to download an ONNX model and tokenizer manually. Its listed text models range from about 120 MB to 1.3 GB and use 384 to 1,024 dimensions. OpenAI embeddings are another feature and require an API key. Memvid can bind a file to a model name to prevent accidental mixing, which is important because indexes built with one embedding space cannot be queried meaningfully with another.
What happened when we ran it
Our sandbox resolved 249 Rust packages in 59 seconds at commit e6bd9f7. The build completed successfully in 105 seconds. The checkout itself contained 217 files, about 70,625 lines of source, and 9.6 MB. Those results came from an unprivileged Rust container with 3 CPUs, 12 GB of RAM, and no secrets.
The test command did not finish within our 900-second cap. The final log showed many named tests ending in ok, but no final count was produced before termination. Three lexical-feature cases had each been running for more than 60 seconds: persistence and search, single-scope operation, and operation through a mutex wrapper. The log does not show whether they were deadlocked, merely slow, or waiting on another condition.
Our run therefore proves that the measured commit installs and builds in the stated container. It does not prove the complete suite passes, and the timeout is especially relevant because all three visible stragglers concern the lexical path. Before adoption, run those cases individually with the exact features, filesystem, corpus size, and release profile intended for deployment. Do not convert the 900-second timeout into a search-latency number; it is a test-completion finding only.
v2.0.140 repaired WAL corruption during growth
The latest release, v2.0.140 from May 27, 2026, fixed a serious storage bug. Sustained put-and-commit work that expanded the embedded WAL could leave a cached payload offset pointing into the newly grown WAL region. Index rebuilding could then overwrite live WAL data, producing checksum mismatches and, in some reports, sparse-file growth beyond the expected end. The fix advances the cached offset with the moved regions and adds a regression case.
The same release fixed temporary Tantivy directories that were left behind after index rebuilds, particularly on Windows. These are credible maintenance fixes with clear causes. They also place the single-file promise in context: avoiding sidecars does not make file-layout code simple. A production team should pin v2.0.140 or newer, preserve older recoverable copies during upgrades, and include repeated WAL growth in its own storage test.
One writer is the clearest architecture limit
Issue 218 describes a multi-agent application where the main session, subagents, and background consolidation all need to write the same memory. The current answer is effectively a central writer or queue. Multiple readers are easier; concurrent mutation is the problem. If the application already needs a durable write service to serialize access, much of the zero-infrastructure advantage disappears and a client-server database becomes more competitive.
Large files have another boundary. Issue 240 says the default maximum sizes for the serialized index and time index are each 512 MiB. The reporter found that a file with a few hundred thousand frames could exceed the cap and fail during open before any query ran. A pull request proposes compile-time tiers up to 4 GiB, which also raise the allocation bound for every file that build opens. Capacity planning belongs in format selection, not after the first oversized capsule.
The README's latency claims need workload reproduction
Memvid's README advertises a 0.025 ms median and 0.075 ms 99th-percentile latency, plus large accuracy and throughput gains. It links those claims to a LoCoMo evaluation using 10 long conversations and an LLM judge. Those figures are project-published benchmarks, not results from our sandbox. Hardware, enabled indexes, corpus shape, cache state, query mix, and comparison systems all matter before applying them to an agent.
The useful decision is narrower. Our 59-second install and 105-second build make the Rust library accessible to evaluate, while the 900-second test timeout prevents a clean quality signal. Memvid is interesting for an offline desktop tool or one agent process that benefits from file transfer and time travel. Shared agents, very large corpora, or high-stakes records should start with concurrency, recovery, and capacity tests, then compare a service database using the same documents and queries.