Liath vs Vector Databases
Vector databases solved a real problem: store embeddings, search them by similarity, filter on metadata. If you are building retrieval, you almost certainly reached for one. But as memory for AI agents, the vector-database shape has three limits worth naming.
Limit 1: one retrieval strategy
A vector database exposes a fixed query: nearest neighbors to a vector, maybe with metadata filters. That is one strategy. Agents want many — recency weighting, importance thresholds, deduplication, cross-referencing — and all of it ends up in application code because the API cannot express it. Liath moves that logic into the engine: the agent writes a Lua program that searches, filters, ranks, and shapes the result in one pass.
Limit 2: a server to run
Most vector databases are network services. You deploy them, secure them, scale them, and pay per query or per vector. For a lot of agents — which are really one process holding a working set of memories — that is a heavy tier of infrastructure. Liath is embedded: a single dependency, in-process, pointed at a data directory. No server, no cluster.
Limit 3: vectors only
An agent’s memory is not just vectors. It is conversation history, tool state, tagged facts with importance, and structured key-value data. With a vector database you bolt those on with additional stores. Liath bundles a key-value store (Fjall), vector search (USearch), and embeddings (FastEmbed), plus agent primitives, so a single Lua program can join semantic memory with everything else.
Where dedicated vector databases still win
This is not “vector databases are obsolete.” If you need to search billions of vectors across a managed, autoscaling cluster, a purpose-built service like Pinecone is exactly right — see Liath vs Pinecone for that trade-off. Liath’s sweet spot is embedded, programmable agent memory, not distributed search at massive scale.
The shift
The move is from storing vectors behind an API to giving agents programmable, embedded memory. Same embeddings underneath; a very different interface on top. If you are building agents, that interface — code the agent writes, run safely in a sandbox — is what unlocks the retrieval strategies a fixed API never could.
Liath is open source (MIT) and on GitHub. Compare it with Chroma, Mem0, and Redis, or read why agents need programmable memory.
Frequently Asked Questions
Is Liath a vector database?
Liath includes vector search, but it is broader than a vector database. It is an embedded memory engine that bundles a key-value store, vector search, and embeddings, and lets agents query all of it by writing sandboxed Lua programs.
Do I still need a vector database if I use Liath?
For embedded, single-process agent memory, Liath can replace a separate vector database because it includes vector search plus key-value storage and embeddings. For managed, autoscaling search over billions of vectors, a dedicated service like Pinecone is still purpose-built.
What does Liath add over a vector database?
Programmable retrieval. Agents write Lua to run search, filtering, ranking, and shaping in one sandboxed execution, and Liath keeps vectors, key-value data, and embeddings in one embedded engine rather than several services.