Liath vs Redis
Redis is a fast, ubiquitous in-memory data store — usually run as a server — with vector search available through modules and support for server-side Lua scripts for atomic operations. Liath is an embedded, programmable memory engine for AI agents: it runs in-process, bundles a persistent key-value store, vector search, and embeddings, and lets agents query memory by writing sandboxed Lua programs with agent primitives like tagged memory, conversations, and tool state. Choose Redis for a networked, high-throughput store; choose Liath for embedded, programmable, agent-native memory.
Verdict: Redis is a fast in-memory data store (with vector search via modules) usually run as a server; Liath is an embedded, programmable memory engine where agents query their memory by writing sandboxed Lua programs.
Liath strengths
- Purpose-built for agent memory with programmable Lua retrieval
- Embedded and in-process: no server or cluster to operate
- Vector search, embeddings, and key-value storage in one dependency
- Agent primitives: tagged memory with importance, conversations, tool state
- Sandboxed Lua blocks file, network, and system access by design
Redis strengths
- Extremely fast in-memory reads and writes
- Battle-tested, ubiquitous, with a huge ecosystem
- Rich data structures and pub/sub for real-time systems
- Vector search available via RediSearch and Redis Stack
- Mature clustering, replication, and persistence options
Overview
Redis and Liath both store key-value data and both can do vector search, but they target different roles. Redis is a fast in-memory data store, usually deployed as a server that many services share, with vector search available through modules. Liath is embedded, programmable memory for AI agents.
Scripting vs programmable memory
Redis supports server-side Lua scripts for atomic operations — a powerful feature, but not a sandbox for agents to write retrieval logic. Liath is designed around the opposite pattern: the agent generates a Lua program that runs semantic search, filters by recency and importance, re-ranks by a custom score, and returns exactly what it needs — safely, because the sandbox blocks file, network, and system access.
Operating model and features
Redis runs as a networked service with mature clustering and replication, optimized for in-memory throughput. Liath runs embedded in your process with no server to operate, and bundles a persistent key-value store (Fjall), vector search (USearch), and embeddings (FastEmbed), plus agent primitives — tagged memory, conversations, and tool state.
When to choose
Choose Redis for a fast shared store or cache across services, rich data structures, and mature clustering. Choose Liath for embedded, programmable agent memory that ships vectors and embeddings in one dependency. Compare also Liath vs SQLite.
Feature Comparison
| Feature | Liath | Redis |
|---|---|---|
| Programmable Lua Queries | Yes | Partial |
| Sandboxed Agent Code Execution | Yes | No |
| Embedded / In-Process | Yes | No |
| Vector Similarity Search | Yes | Partial |
| Built-in Embeddings | Yes | No |
| Key-Value Storage | Yes | Yes |
| Agent Memory Primitives | Yes | No |
| In-Memory Throughput at Scale | Partial | Yes |
| Clustering / Replication | No | Yes |
| MCP Server | Yes | No |
Choose Liath when
- → You want embedded memory with no server to run
- → You want agents to program retrieval and ranking in Lua
- → You want built-in embeddings and semantic search
- → You want tagged memory, conversation history, and tool state
- → You want an MCP server to connect memory to agent frameworks
Choose Redis when
- → You need a shared, networked cache or data store across services
- → You need maximum in-memory throughput and low latency at scale
- → You rely on Redis data structures, pub/sub, or streams
- → You already operate Redis and want to add vectors via a module
- → You need mature clustering and replication
Frequently Asked Questions
Doesn't Redis already support Lua scripting?
Redis supports server-side Lua scripts for atomic operations, but they are not a sandboxed surface for agents to write retrieval logic over semantic memory. Liath is built around agents generating Lua that runs semantic search, filtering, and ranking safely against their memory.
Can Redis do vector search?
Yes, via RediSearch / Redis Stack modules. Liath includes vector search (USearch) and embeddings (FastEmbed) natively in an embedded engine, without running and configuring a server or module.
Is Liath in-memory like Redis?
Redis is primarily an in-memory store optimized for throughput. Liath is an embedded, persistent memory engine using Fjall for its key-value layer, designed for durable agent memory rather than a networked cache.
Do I need to run a server for Liath?
No. Liath is embedded and runs in your process. Redis is typically deployed as a server that multiple services connect to. Liath can optionally run as an HTTP or MCP server if you want a network interface.
When would I still use Redis?
Use Redis when you need a fast shared cache or data store across services, its rich data structures, pub/sub, or mature clustering. Use Liath when you want embedded, programmable, agent-native memory.