FalkorDB vs the leading graph database vendor
Head-to-head query performance across all queries.
Internal benchmark, 170 queries (0–9 hops), same hardware, same dataset.
Securin‘s AI security agents query a large vulnerability knowledge graph 5 to 10 times per user interaction. Each query traverses up to 7 hops across interconnected CVEs, threat actors, ransomware families, attack techniques, and assets.
Their previous graph database averaged 1.43 seconds per query and timed out completely on any traversal beyond 5 hops, a hard ceiling that made their most analytically valuable queries impossible to execute in production.
After migrating to FalkorDB, Securin reduced average query latency to 0.33 seconds, hit 100% success across 170 benchmark queries spanning 1 to 9 hops, and cut end-to-end agent response time from ~15 seconds to under 3 seconds, clearing their 5-second production SLO with room to spare.
About Securin's Threat Intelligence Database
Securin is a cybersecurity intelligence company focused on vulnerability management, threat prioritization, and risk reduction. One of its core offerings, Securin Core, is a large-scale knowledge graph that models the relationships between CVEs, threat actors, ransomware groups, ATT&CK techniques, MITRE mitigations, products, and customer asset inventories. Security analysts and enterprise customers interact with Securin Core through AI-powered CoPilot agents, which are conversational interfaces that translate natural language security questions into multi-hop graph queries and return prioritized, actionable intelligence.
Graph Depth Were Not Optional for Cyber Threat Intelligence
Most (up-to-two JOINS) relational database performance problems are straightforward: a query is slow, you add an index, and it gets faster. Securin’s problem was structural, not indexing-related. Their intelligence questions require the agent to traverse relationships across multiple entity types in a single query. These are not exploratory queries, but the core product.
Consider the following progression of real queries Securin executes against Securin Core, ordered by hop depth:
Query Complexity
Sample Queries
Real-world graph queries ranked by traversal depth. As hop count grows, query complexity rises — and the leading graph database vendor starts failing.
-
hops: 0
"What ransomware families do you track in the dataset?"
-
hops: 1
"What techniques does LockBit typically use?"
-
hops: 2
"How do I mitigate LockBit — what mitigations should I prioritize?"
-
hops: 3
"If LockBit is active, which vendors should I prioritize patching first (based on products impacted by CVEs LockBit exploits)?"
-
hops: 4
"Give me Sigma rules to detect threat actors going after Microsoft Windows."
-
hops: 5
"For Microsoft Windows vulnerabilities, what are the common attack patterns and which ATT&CK tactics do they map to?"
-
hops: 6
"For Windows CVEs, recommend defense tactics and specific defensive techniques (including parent techniques) that protect what attackers go after."
-
hops: 7
"Show me the likely exploitation chain for APT29: what they exploit, the weakness types behind it, and the higher-level technique families/tactics involved."
-
hops: 8
"For a given product category (e.g., 'Endpoint Security'), show how products in that category get attacked (patterns → techniques), what artifacts are involved, and what defense tactics/techniques help."
-
hops: 9
"For that same product category, expand to adjacent/related artifacts too — then tell me which defensive techniques cover that broader set."
A Cypher representation of the 7-hop APT29 exploitation chain query (hops 7) could look structurally like this:
Each hop resolves a new entity type. The query cannot be decomposed into smaller, shallower calls without losing the relational context that makes the answer useful. The agent needs the full traversal in a single round trip, and it needs it fast, because this is one of 5 to 10 calls it makes per user interaction.
“Users would wait 15 to 20 seconds with no response, or receive explicit error messages that the agent could not retrieve information,” said Kiran Chinnagangannagari, CTO and Co-Founder of Securin. “That directly undermined trust in the AI features and had a direct negative impact on our users and business.”
Selecting the Right Database for the Objective
When Securin identified that relational databases could not model the Securin Core graph natively, they moved to a major graph db player, which is purpose-built for connected data.
The chosen graph database is a reasonable choice for many graph workloads. It handles moderate-depth traversals and eliminates database operational overhead. For Securin’s specific workload — high-frequency, deep multi-hop queries driven by an AI agent calling the database 5 to 10 times per user interaction — the graph solution hit three concrete limits:
-
Baseline latency too high for agent-driven access patterns
The leading graph database vendor's average query execution time was 1.43 s (p50: 1.32 s, p95: 2.05 s). A single-query latency in that range is acceptable for many use cases. For Securin's agents, which stack 5 to 10 calls per user interaction, it produces 7 to 14+ seconds of database-induced latency alone — before LLM generation time is added. The cumulative effect consistently pushed agent response times past 15 seconds.
1.43 s Avg query time5–10 Calls per interaction> 15 s Total agent latency -
Hard timeout failures at 5+ hops
The leading graph database vendor begins to experience timeout failures at queries requiring more than 5 hops. In Securin's workload, the 6‑hop through 9‑hop queries — the ones that deliver the most analytically meaningful intelligence — would simply not return. The leading graph database vendor returned no result and no partial answer; it returned a failure. The agent surfaced this as "No information found," destroying user trust.
5 hops Failure threshold6–9 hops Queries that fail0 Partial results returned -
23.5% query failure rate in benchmark testing
In an internal benchmark of 170 queries run on the same hardware under identical conditions, the leading graph database vendor succeeded on 130 and failed on 40 — a success rate of 76.47%. Running a database in production with a one‑in‑four failure rate on complex queries is not a reliability trade‑off — it is an architectural constraint that caps what the product can deliver.
170 Queries tested40 Failed76.47% Success rate
Why Graph is the Right Model for Threat Intelligence
Before examining FalkorDB’s architecture, it is worth being explicit about why a graph database is the correct choice for this workload, and why the hop-depth problem is inherent to the domain, not an artifact of poor data modeling.
Cyber threat intelligence is fundamentally relational. A CVE does not exist in isolation: it has a severity score, it is exploited by specific threat actors, those actors use specific ATT&CK techniques, those techniques require specific system artifacts to execute, those artifacts are present in specific product versions, and those product versions exist in specific customer environments. Answering “Is my organization at risk from APT29 right now?” requires connecting all of those facts. In a relational model, this becomes a series of expensive JOINs across large tables.
In a document store, it collapses the context into nested structures that break traversal. A property graph model makes these relationships first-class citizens of the data structure, enabling Cypher queries to traverse them natively.
The challenge is that not every graph database handles this traversal pattern with equal efficiency, particularly at the latency requirements imposed by an interactive AI agent.
FalkorDB's Architecture: Why Traversal Performance Differs
FalkorDB’s performance on deep multi-hop traversals follows directly from its internal architecture.
Sparse matrix representation via GraphBLAS
FalkorDB represents the graph as sparse adjacency matrices using the GraphBLAS linear algebra library. Graph traversals are executed as sparse matrix operations (matrix-vector multiplications) rather than as pointer-following or index lookups. Multi-hop traversal maps directly to repeated matrix multiplications, which GraphBLAS executes using highly optimized, BLAS-standard linear algebra operations. This means that adding hops to a query does not dramatically increase execution cost the way it does in systems that traverse edges one at a time through memory indirection.
In-memory execution model
FalkorDB holds the full graph in memory and executes all operations from RAM. There is no network round-trip to a storage layer per traversal step. Majority of other graph databases introduce I/O between the compute tier and the storage engine for each traversal. At the latencies Securin requires, this I/O overhead is not negligible, it contributes directly to 1.43-second/query latency on average and its inability to complete deep traversals within timeout thresholds.
Cypher query compilation
FalkorDB compiles Cypher queries into an execution plan that operates over the matrix representation. The planner optimizes traversal order and pushes filters down before the traversal begins, reducing the working set at each hop. The compiled plan is then executed in a single pass through the graph, without re-parsing or re-planning between hops.
Two Deployment Patterns: Persistent Intelligence Graph and Ephemeral Pen Test Graphs
Securin runs FalkorDB in two distinct configurations, each serving a different product requirement.
Persistent Graph: SecurinCore Knowledge Base
The primary deployment is a persistent FalkorDB instance hosting the full SecurinCore knowledge graph. This graph contains all vulnerability intelligence data: CVEs, threat actor profiles, ransomware family relationships, ATT&CK techniques, mitigations, MITRE patterns, Sigma rules, and customer asset mappings. The AI CoPilot agents query this graph continuously during user sessions.
A representative Cypher query for a 4-hop Sigma rule lookup looks like this:
The persistent graph is updated as new threat intelligence data is ingested, and the agents query it live. Latency on this graph directly determines whether the product meets its SLO.
Ephemeral Graphs: Automated Penetration Testing
The second deployment uses FalkorDB Lite, FalkorDB’s embedded, in-process variant. For automated penetration testing, Securin builds a temporary graph of a specific customer environment (network topology, asset inventory, exposed services) at the start of each engagement. The graph exists only in memory for the duration of the operation. When the test completes, the process terminates and the graph is scraped. No customer environment data is written to disk and no data persists between engagements.
Why It Matters
Two Properties That Define the Security Posture
This pattern delivers two specific properties that matter for Securin's security posture.
-
Data Isolation by Design
Because the graph is never persisted, there is no storage layer to secure, no snapshot to audit, and no residual data to manage. The graph lifecycle is bounded by the process lifecycle.
-
Zero-Latency Startup
FalkorDB Lite initializes the in-memory graph from ingested environment data at the start of each test run. There is no remote connection to establish, no cluster to provision, and no cold-start delay waiting for a managed service.
For automated penetration testing, where each engagement operates against a distinct customer environment and customer data must not commingle or persist, this ephemeral graph model is architecturally correct in a way that a persistent managed graph service cannot replicate.
From Decision to Production
The migration from the previous graph database to FalkorDB took approximately two months. This included data pipeline migration, , agent integration, and benchmark validation.
“The convenience of just setting it up and running it stood out,” said Aviral Verma, Head of Research and Threat Intelligence at Securin. “Clear documentation, smooth data loading, and responsive support from the FalkorDB team during graph design and integration made the process straightforward.”
Securin also noted that FalkorDB’s full feature set is available under an open-source license. Features that are gated behind commercial licenses in some graph databases, including the performance-critical execution engine and multitenant architecture, are available to Securin without per-node pricing or enterprise tier dependencies.
Measured Results
170 queries, 0–9 hop depths, production workload.
Query Latency
Average drops from 1.430 s to 0.326 s. p95 is 0.468 s. At 10 graph calls per agent interaction, cumulative p95 latency is ~4.7 s versus the leading graph database vendor's ~20.5 s — a 15-second difference at the tail.
Traversal Ceiling
The leading graph database vendor timed out at 5+ hops, blocking 6–9 hop queries entirely — exploitation chain analysis, cross-product defense mapping, full ATT&CK tactic coverage. FalkorDB runs all of them with a flat latency profile. The 7-hop APT29 chain completes in under 400 ms.
Query Success Rate
Leading graph database vendor: 130/170 succeeded, 40 failed. FalkorDB: 170/170 succeeded, 0 failed. Eliminating the failure rate removed the primary source of agent hallucination and "no information found" errors in production.
Agent Response Time (E2E)
10 calls × 1.43 s = ~14.3 s graph time on the leading graph database vendor. 10 calls × 0.33 s = ~3.3 s on FalkorDB. Total agent response drops from ~15 s to ~3 s, clearing the 5-second production SLO.
This case study is based on an internal benchmark conducted by Securin on the same hardware, using the same dataset and query set to evaluate FalkorDB.
