Liath vs SQLite
SQLite is the world's most deployed embeddable SQL database — a general-purpose, tiny, universally portable relational engine. Liath is the SQLite for AI agents: it shares the embedded, zero-infrastructure model but is purpose-built for agent memory, with programmable sandboxed Lua queries, built-in vector search and embeddings, key-value storage, and agent primitives on a Rust core. Choose SQLite for general relational storage; choose Liath for embedded AI agent memory.
Verdict: SQLite is the world's most deployed embeddable SQL database; Liath is the SQLite for AI agents — embedded like SQLite, but built for agent memory with programmable Lua queries, vector search, and embeddings.
Liath strengths
- Purpose-built for AI agent memory, not general SQL storage
- Agents query memory by writing sandboxed Lua programs
- Built-in vector search and text embeddings alongside key-value storage
- Agent primitives: tagged memory with importance, conversations, tool state
- Rust core with library, CLI/TUI, HTTP, and MCP interfaces
SQLite strengths
- The most deployed database in the world, on billions of devices
- Rock-solid, extensively tested general-purpose SQL engine
- Tiny footprint and zero configuration
- Universal platform and language support
- Public domain, with decades of stability and tooling
Overview
Liath borrows SQLite’s best idea — an embedded database that runs in your process with zero infrastructure — and applies it to a different problem. SQLite is a general-purpose SQL database. Liath is programmable memory for AI agents.
Same embedded model, different purpose
Like SQLite, Liath has no server, no cluster, and no configuration ceremony: a single dependency pointed at a data directory. But where SQLite gives you tables and SQL, Liath gives you a key-value store, vector search, embeddings, and a sandboxed Lua query surface designed for how agents recall information.
What SQLite would need bolted on
To use SQLite as agent memory, you would add a vector search extension, wire up an embedding pipeline, and implement retrieval, ranking, and importance-weighting in application code. Liath ships all of that: store_with_embedding, semantic_search, tagged memory with importance, conversation history, and tool state — queried by Lua programs the agent writes.
When to choose
Choose SQLite when you need a general-purpose relational database with the smallest footprint and universal portability. Choose Liath when you are building agent memory and want vector search, embeddings, and programmable retrieval in one embedded engine. For application data in AI-era apps, also see the sibling database ORMDB, and compare Liath vs Redis.
Feature Comparison
| Feature | Liath | SQLite |
|---|---|---|
| Programmable Lua Queries | Yes | No |
| Embedded / In-Process | Yes | Yes |
| Vector Similarity Search | Yes | No |
| Built-in Embeddings | Yes | No |
| Key-Value Storage | Yes | Partial |
| Agent Memory Primitives | Yes | No |
| General-Purpose SQL | No | Yes |
| Tiny Footprint | Partial | Yes |
| Universal Portability | Partial | Yes |
| MCP Server | Yes | No |
Choose Liath when
- → You are building AI agent memory rather than general application storage
- → You want vector and semantic search built into the engine
- → You want agents to program retrieval and ranking in Lua
- → You need tagged memory, conversation history, and tool state
- → You want an MCP server to expose memory to agent frameworks
Choose SQLite when
- → You need a general-purpose relational database
- → You need the smallest possible footprint and universal portability
- → Your data model is tabular and SQL fits it well
- → You want the most battle-tested embedded engine available
- → You do not need vector search or programmable agent memory
Frequently Asked Questions
Why is Liath called the SQLite for AI agents?
Because it shares SQLite's embedded, zero-infrastructure model — it runs in your process as a single dependency, pointed at a data directory — but it is built for agent memory: programmable Lua queries, vector search, embeddings, and agent primitives instead of general-purpose SQL.
Can I use SQLite for agent memory instead?
You can store data in SQLite, but you would need to add a vector search extension, an embedding pipeline, and your own retrieval logic in application code. Liath bundles vector search, embeddings, and programmable Lua retrieval into one engine designed for agents.
Does Liath replace SQLite?
No. SQLite is a general-purpose SQL database and remains the best choice for tabular application data with the smallest footprint. Liath is specialized for AI agent memory. Many stacks would use both.
Is Liath as portable as SQLite?
SQLite runs virtually everywhere. Liath is written in Rust and supports major platforms, but it does not match SQLite's universal portability. Its advantage is agent-native memory features.
Does Liath use SQL?
No. Liath's query language is sandboxed Lua, which lets agents express custom retrieval and ranking as programs. SQLite uses SQL.