AML
Wire-to-address exposure trail.
5hops · one query
bank → wire → txn → account → address. Cypher inside, SUM/COUNT outside, live on the wires table.
Graph queries that see your whole table.
GraphDistributedSQLHybrid
One grammar for geospatial, social, and property graphs. Topology stored in fixed memory. Traversals restricted by the same SQL you write on the rest of your data — no copy, no sync, no second engine.
Start FreeSolve · Match · Query — all in standard SQL
Stop choosing between graph speed and analytical breadth — keep the graph beside your data, not on a copy.
Neo4j · TigerGraph · DuckPGQ
Built for traversal — but it lives apart from your data.
Fastest at pure-graph workloads when the graph is static. The cost: topology is a copy, attributes are duplicated or streamed in via hooks, and joins back to relational data live in application code or batch jobs. Single-node engines (DuckPGQ-class) cap at one machine's memory.
High traversal performance on static graphs
Explicit duplication; attributes must be synced
No native OLAP — analytics happen elsewhere
Single-node ceiling — no distribution past one host
Cypher you already know. SQL you already write. One planner.
Kinetica is GQL-compliant and supports Cypher in full — the patterns your team writes against Neo4j port over unchanged. Wrap any match in GRAPH_TABLE() and it becomes a table-valued function: GROUP BY, window functions, joins, and OLAP aggregates compose with graph traversal in a single SQL statement.
SELECT person, bank, SUM(amount), MAX(risk_score) FROM GRAPH_TABLE( GRAPH expero.banking_graph MATCH (a:bank)-[:performed]->(b:wire_message WHERE b.risk_score > 20) -[:is_for_transaction]->(c:banking_transaction) RETURN g.party_name AS person, a.bank_name AS bank, c.amount, b.risk_score ) GROUP BY person, bank ORDER BY SUM(amount) DESC;
O(1) upserts mean your graph never falls behind your data.
Edge insert and delete are pointer operations, so source-table changes propagate to the graph topology in constant time. Turn on add_table_monitor and the graph stays in sync with your CDC stream, your Kafka feed, your trickle-load — no batch rebuild, no nightly reload, no stale topology.
CSR-based engines
Batch reload window. Topology lags ingest. Streaming graphs require external rebuild jobs.
Kinetica · DLS
Graph queries while you ingest. No rebuild window. No stale topology — the graph follows the tables, the tables follow the stream.
Who it's for
AML wire-tracing · real-time fraud rings · fleet & IoT telemetry · supply-chain visibility · social-network freshness.
Solve. Match. Query. Every operator your workload needs.
Generic solvers (shortest path, PageRank, centrality), purpose-built matchers (supply-demand MILP, HMM map-matching, fraud-ring loops), and label-aware traversals with OLAP filters — four of them patented Kinetica research, all callable in SQL.
/solve/graph
Solve
Network-agnostic algorithms on any graph: shortest paths, TSP, backhaul routing, PageRank, centrality, all-paths enumeration.
shortest_path · multiple_routing · page_rank · centrality · inverse_shortest_path
/match/graph
Match
Higher-order solvers for routing, fraud, scheduling, and supply chain. Patented algorithms anchor this family.
match_supply_demand · map_matching HMM · loops (fraud rings) · clusters (Louvain · RSB) ·
batch_solves
/query/graph
Query
Hop-based pattern queries with node and edge labels. Restrictions reference any column on any table — even columns the graph has never seen.
adjacency · pattern_matching · hop-based query · OLAP column expressions inside traversal
Three workloads. Three architectures. One engine.
Each runs today against a live Kinetica graph, end-to-end, in a single SQL statement — no sidecar solver, no separate spatial engine, no batch job.
Emergency response
Closest of 1,700+ fire stations.
1.7Korigins → 1 disaster
1.5M-edge road graph, inverse many-to-one Dijkstra, animated SVG of every candidate route.
Logistics
Two depots. Twelve trucks. Partial loads.
12trucks · MILP
match_supply_demand with multi-modal AIR · SEA · LAND edge labels and partial mid-route drops.
Production results on real hardware — dated and attributed.
Numbers from production builds and POCs, not marketing slides. Full benchmark refresh in progress.
Shortest path · 5 locations
~250ms
500K-edge Seattle road network, multi-source / multi-target, distance ÷ speed weights.
7.1.10.2 / 7.2.0.7 builds · Q3 2024
Multi-billion edge · 3-hop
1.2–1.8sec
4.3 B edges, 2.8 B vertices, source-to-many on a single node with 1 TB RAM + 0.5 TB ZRAM.
POC build · 2024
Partition rebalance
100×faster
Distributed cross-partition shortest path vs random partitioning.
arXiv:2201.02136 (2022)
One engine. Every graph. The one your analytics already speak to.
Frequently asked questions
How is Kinetica's graph database different from Neo4j or TigerGraph?
Dedicated graph databases store topology in a system that's separate from your relational data —
which means attributes get duplicated and joins back to tables happen in application code.
Kinetica keeps topology and attributes in the same engine:
NODE, EDGE,
WEIGHTS, and RESTRICTIONS are annotated column references on existing
tables, so a graph traversal can filter on any column without copying or syncing anything.
What is the Double-Link Structure (DLS) and why does it matter for streaming graphs?
Standard graph storage uses Compressed Sparse Row (CSR), where edges are packed contiguously by
source node. An insert on a busy node forces every downstream cell to shift in memory — an O(n)
cost per edge. DLS uses fixed-size linked cells: each edge costs two pointer writes, an O(1)
operation, so the graph holds its shape under continuous upserts instead of waiting on a batch
rebuild. The architecture is documented in
arXiv:2201.02136.
Can graph traversals filter on columns that aren't part of the graph?
Yes — and that's the point of the hybrid architecture. Pass a SQL
SELECT as the
RESTRICTIONS argument to QUERY_GRAPH and the predicate is evaluated by
the distributed OLAP engine for every candidate node during the walk. Failed nodes are pruned
mid-traversal. The filter can reference any column on any table in the database, including columns
the graph has never seen.
What graph algorithms ship with Kinetica out of the box?
Three endpoint families, all callable from standard SQL:
Solve (
shortest_path, multiple_routing/TSP,
backhaul_routing, page_rank, probability_rank,
centrality, closeness, stats_all,
inverse_shortest_path), Match (match_supply_demand,
map_matching, charging_stations, pickup_dropoff,
loops, similarity, clusters via Louvain/RSB,
pattern, batch_solves — four of which are patented), and
Query (label-aware hop-based traversals with OLAP restrictions).
How big a graph can Kinetica hold, and how fast can it traverse it?
On a 500K-edge Seattle road network, a multi-source
SHORTEST_PATH over five lon/lat
pairs returns in roughly 250 ms. On a single node with 1 TB RAM + 0.5 TB ZRAM, Kinetica has held a
4.3 B-edge / 2.8 B-vertex graph and run 3-hop source-to-many queries in 1.2–1.8 seconds.