Memory Architecture: The 3-Tier Hybrid System
Why vector search alone isn't enough — and how combining SQLite+FTS5, LanceDB, and memory.md creates a personal assistant that truly remembers.
SQLite+FTS5
80% of lookups
LanceDB
Semantic recall
memory.md
Always in context
The Memory Problem
Most OpenClaw users start with a single approach to memory: either a vector database or a flat memory.md file. Both work — until they don't. Vector search is brilliant for fuzzy semantic recall, but it's expensive and imprecise for factual lookups. A plain text file is always in context, but doesn't scale. The solution? A 3-tier hybrid architecture that covers the full spectrum.
The 3-Tier Architecture
Precise factual retrieval with zero external dependencies. Covers 80% of what a personal assistant actually needs — dates, names, preferences, decisions. Full-text search via FTS5 makes it fast and flexible.
Fuzzy semantic recall for contextual associations. When you ask 'what was that conversation about the restaurant last week?', vector search finds it even if you don't remember exact words.
Critical information that must always be in the LLM's context window. Your name, preferences, key relationships, active projects. Small, curated, always present.
Why Not Just Vector Search?
I went straight to LanceDB because vector search felt like the 'AI-native' approach. But for a personal assistant, most memory queries are structured lookups. SQLite + FTS5 would have covered 80% of my needs from day one with zero external dependencies.
Vector search excels at fuzzy semantic recall — 'find conversations similar to X'. But it's overkill for 'what's my partner's birthday?' or 'what model do I use for heartbeats?'. Those are structured facts that a simple database handles better, faster, and cheaper.
A hybrid approach — structured storage for precise facts, vector search for contextual recall, always-loaded context for critical information, and time-aware decay for managing freshness — covers the full spectrum.
Memory Approaches Compared
| Approach | Strengths | Weaknesses | Best For |
|---|---|---|---|
| memory.md only | Always in context, simple | Doesn't scale, manual curation | < 50 key facts |
| Vector DB only | Semantic search, scales well | Expensive, imprecise for facts | Large unstructured memory |
| SQLite + FTS5 only | Fast, precise, zero deps | No semantic understanding | Structured fact lookup |
| 3-Tier Hybrid ✅ | Complete coverage | More complex setup | Production personal assistant |
Dependencies & Setup
better-sqlite3@11.0.0SQLite driver with FTS5 full-text search@lancedb/lancedb@0.23.0Embedded vector database for semantic searchopenai@6.16.0Generate embeddings (text-embedding-3-small)@sinclair/typebox@0.34.47Runtime type validation for plugin configsBuild Requirements
API Keys
OPENAI_API_KEYRequiredRequired for embedding generation (text-embedding-3-small)SUPERMEMORY_API_KEYOptionalOptional — cloud archive for Tier 2 backupsDaily Fact Extraction
The system includes a CLI command that scans conversation logs, extracts structured facts, and backfills them into the SQLite database. Think of it as a safety net — conversations that slip through real-time capture get caught in the daily sweep.
Design Principles
Design for decay from the start
Add TTL classification early. Without it, stale facts accumulate and clutter retrieval results. A fact about 'today's meeting' shouldn't persist for months.
Extract decisions explicitly
Don't store raw conversation logs — they're noise. Store distilled decisions with rationale. 'Chose Haiku for heartbeats because it's cheapest' is more useful than 500 tokens of discussion.
Hybrid beats pure
No single memory system covers all query patterns. SQLite for facts, vectors for vibes, memory.md for identity. Each layer has a clear job.
Zero-dependency first
Start with SQLite+FTS5 — it covers 80% of needs with zero external services. Add vector search only when you actually need semantic recall.