Three-store knowledge materialization architecture patterns for stupid-db
stupid-db unifies three database paradigms behind a single write interface:
| Store | Purpose | Backing | Hot Path |
|---|---|---|---|
| Document | Raw event storage, filtered scans | Time-partitioned mmap segments (MessagePack) | SegmentReader scan with predicate push-down |
| Vector | Semantic similarity, clustering input | Per-segment HNSW index | Cosine similarity search |
| Graph | Entity relationships, traversals | In-memory property graph (adjacency list) | PageRank, Louvain, degree queries |
All three stores are populated automatically from a single document insert. Users never interact with vector or graph stores directly.
Source (Parquet/S3/SQS/Athena)
→ Ingest (parse, validate)
→ Connect (entity extract + embed + link)
→ [Document Store | Vector Index | Graph Store]
→ Compute (continuous background algorithms)
→ Catalog (queryable metadata)
→ Query (LLM-powered NL → SQL)
→ Dashboard (D3.js visualization)
Dependencies flow upward — core has zero internal deps:
Layer 0: core (types, Config, Document)
Layer 1: rules, segment, graph, llm
Layer 2: compute, connector, ingest, storage, catalog
Layer 3: server, tool-runtime, agent
Layer 4: mcp, cli
Standalone: notify, queue, athena
Critical rule: No dependency cycles. If crate A depends on B, B must NEVER depend on A.
Active (writing) → Sealed (read-only) → Archived (cold) → Evicted (dropped)