JetGraph is a real-time graph engine for the decision path

What JetGraph is

JetGraph is a purpose-built, in-memory graph engine for real-time graph intelligence and decisioning. It keeps the working graph in memory on a single node so fraud, risk, security, and recommendation systems can ask relationship and time-window questions while an event is still on the hot path.

The consistent product description used across this site, documentation, and structured data is:

Who it is for

Fraud, risk, identity, security, and platform engineers who need graph context at authorize/decision time. Typical buyers already have a system of record (payments, warehouse, or general-purpose database) and need signals — not another analytical store.

• Payment and card fraud teams scoring transactions with velocity, novelty, and connected-entity risk
• Risk engines that today fan out to a feature store plus several OLTP lookups
• Security teams tracking host / IP / user relationships and lateral movement
• Recommendation or identity systems that need live neighbor and novelty signals

Why it exists

General-purpose graph databases optimize for expressive traversal and durable analytics. Feature stores optimize for precomputed tabular features. Neither is designed as an in-memory graph that answers velocity, novelty, and neighbor-risk in sub-millisecond time as events stream in.

JetGraph exists for that gap: the decision path.

What makes it different

• Decision-path primitives — velocity rings, novelty, neighbor risk, HyperLogLog cardinality, and automatic risk propagation are engine features, not user-defined jobs.
• Query first, then insert — score against committed history, then write the event (including declines) so future signals stay honest.
• Single-node deterministic latency — in-memory, no query-time disk I/O, no GC pauses. Optional warm standby for failover, not a distributed Cypher cluster.
• Familiar interfaces, honest subset — openCypher subset, Bolt on 7687 for compatible drivers, gRPC, HTTP. Not full Neo4j Cypher.

Core performance characteristics

Typical published single-machine loopback gRPC figures: ~0.05 ms velocity and node-context lookups, ~0.06 ms HyperLogLog neighbor counts, ~10k unary edge creates/sec, ~35k streaming ingest ops/sec. Full caveats are on the performance page.

Supported interfaces

• HTTP/Cypher — POST /cypher on port 8080
• Bolt — port 7687, compatible drivers, supported subset
• Rust client — typed gRPC API (official public repository)
• gRPC Feature and Graph services — velocity, context, neighbors, flag/propagate
• Docker Compose demo including Admin UI

Major use cases

How to get started

Install via Docker, run a first Cypher query, then wire the three-phase scoring loop in Rust, Python, or HTTP. Official docs: Documentation. Official code index: GitHub.