Skip to main content
LanceDB is sovseal’s local vector store — the only vector store in the system. All semantic search (recall_memory / client.recall()) runs against it, entirely on-device.
There is no remote or server-side vector store. The replication server never receives embeddings — only encrypted text and metadata. If you’re looking for how remote data is stored, see Storage Architecture: it’s two Postgres tables plus a ciphertext bucket, not a vector database.

​
How local search works

LanceDB runs as an embedded serverless library inside your agent or MCP server process — no background daemon, no connection management. Queries execute in sub-10ms (6.1ms p50 warm recall) using vector search over Float32 normalized vectors.

​
File System Layout

  • Default Database Location: ~/.sovseal/db/
  • Memories Table Path: ~/.sovseal/db/memories.lance/
  • Override with the SOVSEAL_DB_DIR environment variable.
The table directories contain Arrow metadata files, schema configurations, and transaction logs. No background process is run.

​
Arrow Table Schema (v2)

See Memory Model for what these fields mean at the record-shape level, not just the storage level.

​
Thread Safety & File Locking

  • Reader Isolation: Multi-threaded read queries are non-blocking — multiple agents or editor panels can call recall_memory simultaneously.
  • Writer Coordination: Writes are serialized via internal file-locking.
  • Transaction Log: LanceDB uses append-only transaction logs. If your machine crashes mid-write, the database recovers to the latest consistent state on next start.

​
Replication (what leaves the device)

When you configure an API key and endpoint, a background SyncWorker monitors local rows with sync_status = 'pending', encrypts them client-side with AES-256-GCM, and pushes ciphertext to the edge endpoint — see Replication & Sync for the full batching, retry, and conflict-handling behavior. The vector column never replicates; only encrypted text and non-secret metadata do.