enhancement: What do you think about adding vectors too?

[pjv]

@Alan-TheGentleman

Engram is a very cool tool which I have been working with for a week or so now on a bot project that I hope is going to replace me as first line tech support on a company chat server.

Stumbled on this git issue when i was looking for something and it made me wonder how hard it would be to integrate one or another sqlite vector plugin in engram and whether you think that would be a worthwhile addition to the project.

asg017/sqlite-vec#48

some links:
https://github.com/sqliteai/sqlite-vector
https://medium.com/@stephenc211/how-sqlite-vec-works-for-storing-and-querying-vector-embeddings-165adeeeceea

[Alan-TheGentleman]

Hey @pjv, thanks for trying engram out and for the thoughtful suggestion!

I did a deep dive into the options. Here's where I landed:

Why NOT Turso/libSQL

@josecanciani suggested libSQL (Turso) in #21 as a drop-in replacement. After investigating, it's not viable for engram:

• Requires CGO (go-libsql needs CGO_ENABLED=1). Engram currently uses modernc.org/sqlite — pure Go, zero CGO. This is what lets us ship a single static binary that cross-compiles everywhere.
• No Windows support — go-libsql only ships precompiled libs for linux/darwin (amd64/arm64). We just added Windows support and it's already being used.
• File format risk — vector columns in libSQL may not be readable by standard SQLite tools, requiring migration for existing users.

This would fundamentally break engram's "zero dependencies, single binary, runs anywhere" philosophy.

sqlite-vec is more promising (but still has tradeoffs)

sqlite-vec is a pure C SQLite extension — small, no dependencies, runs anywhere. It's a better fit architecturally. But the real question is: where do the embeddings come from?

Approach	Pros	Cons
External API (OpenAI, Ollama)	High quality embeddings	Adds config complexity, network dependency, API costs — breaks "zero dependencies"
Bundled model (GGUF via sqlite-lembed)	No external dependency	Binary bloats from ~15MB to 100MB+, build complexity explodes
Agent generates embedding at save time	Zero new dependencies — the LLM already processes the text	Adds a new MCP tool param, embedding quality varies by model, not all agents support embedding APIs

Current reality: FTS5 works well for this use case

Here's the thing — agents don't search like humans. They save structured content with explicit keywords (**What**: Fixed N+1 query, **Where**: src/store/store.go), and they search with specific terms. FTS5 full-text search handles this really well because the content is keyword-rich by design.

Semantic search would help with ambiguous natural-language queries ("that thing we did with the database"), but in practice agents are precise searchers.

Path forward

If we add vector search, the most likely approach is:

1. FTS5 stays as the default — no changes for existing users
2. sqlite-vec as an opt-in extension — engram --experimental-vector or a config flag
3. Agent-side embeddings — add an optional embedding param to mem_save. The LLM generates the vector (many already support embedding APIs). No bundled model, no external API requirement.
4. Hybrid search — FTS5 for keyword recall + vector for semantic recall, merge results

I'm keeping this open as a feature discussion. If you want to prototype the agent-side embedding approach, PRs are very welcome!

[pjv]

Yup, where you landed on a high level is what i vaguely had in mind. For me, an optional embedding param where i can choose the provider / URL etc for an embedding model (i self-host so for me that would be a local LLM) would be perfect. I imagine that 99.9% of engram users have easy access to an embedding model they could specify.

Here's a practical use-case example. As I mentioned, my first use of engram is prototyping a chat bot that i hope will replace me to some degree on a company chat server for front-line tech questions that have been answered many times in the past. I've been feeding old chat threads into engram and then throwing test questions at the LLM. I stumbled onto a question about the number of SKUs that the company sells via the company website. As it happens, there was a post that had been stored in engram that specified the number (a range actually), but the way the bot model phrased the search it happened not to get a hit due to using the word "sales" rather than the word "sold" in the search phrase. I tried the same question several times with several different models behind the bot agent and more often than not, the search phrase the model used (in response to the same question) did get a hit on the post in question and the model did answer the question correctly. But on the rare occasions that it missed with the FT search, I have a strong intuition it would have gotten a hit with a vector search. And that's what prompted me to open this issue.

[Alan-TheGentleman]

Already discussed above — FTS5 covers the current use case well since agents save structured summaries with explicit keywords. Semantic/vector search is on the long-term radar but not prioritized right now. Thanks for the input!