real-time GraphRAG engine · optimized for LLMs

The knowledge graph your agents can query in real time.

StromaDB fuses vectors × types × time in one engine: a streaming knowledge graph where an LLM agent runs type-aware hybrid search, reads any stored fact as it was at any past moment, and gets an answer that shows where it came from — while the graph keeps ingesting underneath.

Rust · single binary · Elastic License 2.0 · MCP-native
POST /query
request — point, as of a valid-time
// who was the dept manager at approval time? { "op": "point", "subject": 42, "predicate": "manager-of", "valid_at": 1719800000 }
response — value + provenance + confidence
{ "one": { "node": 12 }, "provenance": "workday-hr", "confidence": { "tier": "high", "corroboration": 2 } }
Built-in console

Explore the graph, search by type, inspect a node — live.

The engine ships a GPU-rendered graph explorer, stroma-serve: walk a neighbourhood, run a type-aware vector search, and inspect any node down to its embedding — all against the live graph.

The StromaDB web console: a GPU-rendered graph explorer with type-aware vector search and a node inspector panel
How it works

A stream goes in. An agent reads meaning, structure, and time back out.

Live stream / CDC facts · out-of-order · multi-source StromaDB typed graph · vectors · two timelines crash-safe on disk · reads never block Agent reads any past moment · type-aware · shows sources summaries & facts written back
Capabilities

One engine for the way agents actually read a graph.

Retrieval that is semantic, structural, and temporal at once — not a vector store bolted to a graph db.

Type-aware hybrid search

Vector search filtered by node type, graph structure, and per-user permissions — so an approximate match never returns the semantically-close but wrong node. Types come from a lightweight ontology that says which types each relationship can connect, how many are allowed, and what extra attributes it can carry — no axioms, no reasoner.

finds ~all the relevant results

Read any moment in the past

Every fact records the span of time it was true. Ask for the value that was in effect at any instant — "who approved this, as things stood at approval time" — not just the latest write.

two timelines · query any point in time

Real-time under writes

Reads never block, even while a long streaming ingest is running — and every read sees one consistent moment of the graph.

99% of reads finish within 1.32ms, even during a concurrent write

Declared rules → verdicts

Evaluate a rule you declare against the graph, deterministically: what's expected but missing, and what's present but wrong — traced back through the chain of relationships that led there, as it stood at the relevant past moment. No reasoner.

checks correctness & completeness

Durable by design

Every write lands safely on disk before it counts, committed in batches. After a crash, cold-start replays everything that was committed and drops any half-written tail using a checksum — nothing committed is lost.

cold-start recovery 0.81s @5M facts · 0 data loss

Agent-native (MCP)

Ships a Model Context Protocol server: an LLM discovers the schema and calls the graph as tools — schema, point, expand, search, conformance — over stdio.

works with Claude, GPT, any MCP client
Measured

Numbers, taken under unfriendly conditions.

Measured at representative scale on hard data.

<2ms
99% of combined reads finish under this — approximate vector search plus graph expansion, over the durable on-disk graph
~1.0
of the relevant results come back — even on hard data where clusters overlap
0.81s
cold-start recovery at 5M facts — zero data loss
32×
vector compression with exact re-rank
For agents

Hand the deterministic part to the engine.

An LLM is great at orchestration and language, but unreliable at exact graph logic that follows a long chain of relationships and depends on how things stood at a past moment. So the engine evaluates declared rules and returns a deterministic verdict; the agent calls it and acts.

declare a rule once
// approver = manager of the assignee's dept,
// as of the approval time
{ "op": "conformance",
  "rule": {
    "subject_type": "Issue",
    "required": { "hops": [
      {"predicate":"assigned-to"},
      {"predicate":"member-of"},
      {"predicate":"manager-of",
       "as_of":"approved-at"} ] },
    "actual": "approved-by" } }
get a verdict per subject
{ "verdicts": [
  { "subject":1001, "verdict":"OK" },
  { "subject":1004, "verdict":"MISMATCH",
    "kind":"wrong" },
  { "subject":1005, "verdict":"MISMATCH",
    "kind":"stale",     // approved by a
    "required":{"node":12}, // past manager
    "actual":{"node":10}, "as_of":6000 }
] }
01 · ingest

Stream facts

Multi-source events fold into a typed graph, each fact tagged with when it was true and where it came from.

02 · retrieve

Type × vector × time

The agent pulls context that's relevant by meaning and by structure, as it was at any past moment.

03 · evaluate

Rules → verdicts

The engine deterministically flags absent / wrong / stale — no reasoner.

04 · act

Agent orchestrates

The LLM interprets verdicts and acts, holding no exact graph logic itself.

Self-host it. Embed it. Query it from any agent.

A single Rust binary — HTTP and an MCP stdio server. Elastic License 2.0: self-host, modify, and embed freely.