← Tech
Exploration Design stage — this describes architecture being explored, not what's currently built.
"Use one vector DB?" Poor precision Hybrid: 3 storage types Exact + Semantic + State

Decision: Hybrid Storage Over Pure Vectors

21 Mar 2026 · Tristan Wright

Context

When designing CollectHive’s memory system, we researched five existing memory architectures: mem0, Memori, agent-recall, coolmanns/openclaw-memory-architecture, and GitHub Copilot’s approach.

The convergent finding: pure vector storage doesn’t work for inspectable, debuggable AI memory.

The Problem With Pure Vectors

When a user asks “why does my agent think I use Stripe?” — with vectors, you can’t answer that. You can search for similar embeddings and hope something relevant comes back, but you can’t point to a specific record, show its source, and let the user correct it.

Vectors are great for fuzzy recall (“what were we discussing about pricing?”) but terrible for factual lookups (“what payment provider does Project Alpha use?”).

Decision

Use three storage backends, each optimised for a different query pattern. This decision has been made but not yet implemented — the current system uses a single memories table in Convex with type classification.

  • Facts (structured, entity/key/value with full-text search) — target: 80% of queries. Exact, inspectable, debuggable.
  • Conversations (vector-indexed) — target: 15% of queries. Semantic similarity for fuzzy recall.
  • Decisions (structured with side effects) — target: 5% of queries. Active configuration that triggers capabilities.

What We Rejected

Pure vector — can’t answer “why does my agent think X?”, can’t debug wrong facts, can’t do exact lookups efficiently.

Pure structured — loses fuzzy recall entirely. “What were we talking about last week?” becomes impossible without semantic search.

Single hybrid (vectors with metadata) — bolting structured queries onto a vector database is possible but fragile. Query patterns diverge too much. Better to use purpose-built backends and merge results at the API layer.

Consequences

Positive:

  • Facts are trivially inspectable: entity=project_alpha, key=payment_provider, value=Stripe, source=session_abc
  • Users can correct wrong facts directly
  • Decisions activate capabilities automatically (choosing Stripe suggests the Stripe skill)
  • Each backend can be optimised independently

Negative:

  • More complex than a single vector store
  • Unified search API must fan out and merge results
  • Extraction pipeline must classify knowledge into the right backend
  • Three storage schemas to maintain

We accepted the complexity because inspectability is non-negotiable for a team-shared memory system. When someone’s agent gives bad advice, the team needs to find and fix the source — not hope a re-embedding fixes it.