Graph Engines: the layer where graph-shaped computation runs over your existing systems instead of inside a new database of its own.
Graph engines turn warehouses, relational databases, event streams, and application platforms into graph-native environments, projecting nodes and relationships on the fly so you can ask graph questions without rebuilding your stack.
This catalog focuses on offerings where the engine itself is the main event: projecting graphs over other data platforms, running traversals and algorithms in place, and doing so in a way you can actually deploy and operate. It is not a list of every database that happens to ship a few built-in graph procedures.
We see graph engines emerging as a distinct layer of the graph stack, sitting between data platforms and applications. They matter when you want graph intelligence but cannot, or do not want to, move everything into a dedicated graph database.
What We Included in Graph Engines
The goal of this catalog is to surface engines that compute over existing systems, not those that become a new system of record. In this first version, you will see offerings that:
- Project graphs over relational data and warehouses
- Run graph analytics as a coprocessor inside platforms like Snowflake
- Build streaming graphs directly from Kafka- or Kinesis-style event streams
- Expose in-engine algorithms and APIs rather than only visual tooling
For each entry, we track attributes specific to this category.
Availability and Deployment records whether the engine is open source or commercial and whether it runs as SaaS, is managed in the customer’s cloud, or is fully self-managed.
Query Languages notes which graph or host languages you use to define graph projections and run computations, such as Cypher, Gremlin, SQL, or proprietary languages like Rel or xGT APIs.
Workload Focus describes whether the engine is aimed at analytics and OLAP, streaming and real-time workloads, operational graph logic, or a combination of these.
Graph Analytics Offering and Built-in Algorithms indicate whether algorithms are built into the engine, what is available out of the box such as PageRank, centrality, community detection, shortest paths, and how much is left to custom logic.
Data Sources summarizes which upstream systems the engine can operate over, including relational databases, warehouses, files and object stores, event streams, and application-specific data such as SAP application tables or geospatial layers.
The intent is to let you answer questions like:
- Which engines can I drop in if my data already lives in Snowflake or another warehouse
- What can I use to build a streaming graph directly over Kafka or Kinesis
- Which products give me built-in algorithms versus expecting me to implement everything with low-level APIs
Inclusion Criteria: When Is Something a Graph Engine
To keep the category focused, we apply three inclusion criteria. An offering belongs in the Graph Engines catalog only if it satisfies all three.
No Primary Graph Storage of Its Own
The product must not be a general-purpose graph database where the engine and storage are tightly coupled. Instead, it runs graph computations over data stored in other systems such as databases, warehouses, event streams, or application platforms, or it reuses an existing platform’s storage layer, for example an engine embedded in a relational or multimodel database.
Graph databases where the engine and storage are inseparable live in the Graph Databases catalog, not here.
Graph Computation Layer over Existing Platforms
Graph traversal and analytics must be core to the product, not incidental. In practice this means there is a clear API, language, or module for graph queries and algorithms; you can run standard graph workloads such as pathfinding, centrality, community detection, and neighborhood exploration through built-in functions, procedures, or libraries; and the engine is chosen because of its graph computation capabilities, not only for visualization or generic ETL.
This draws a line between engines and purely visual tools that rely on external graph databases for all computation.
Exposes Graph Query and Analytics as a Service
The engine must have a clear, documentable answer to how it runs and where it reads from. We look at its deployment model, such as open source or commercial, SaaS, managed in the customer’s cloud, or self-managed, as well as which systems it can operate over, including SQL stores, warehouses, streams, files, and application data, and whether it is tightly coupled to one host platform or designed to span many.
This gives practitioners a way to filter by constraints like not being able to move off Snowflake, needing to run in their own VPC, or wanting to compute over event data without inserting a new database in the middle.
What the First Version Tells Us
Even in this first pass, a few patterns are already visible:
- Graph engines are gravitating toward where data already lives, especially warehouses, relational stores, and embedded platforms, rather than asking teams to stand up yet another database.
- Streaming-focused engines are emerging as a distinct pattern, maintaining continuously updated graphs directly over event streams for real-time use cases.
- Many engines are explicitly memory-first, using in-memory graph execution for speed while delegating durability and long-term storage to the underlying data platforms.
This is the kind of structure State of the Graph is meant to provide: not just which names exist, but how their roles differ and where they plug into existing architectures.
How Graph Engines Fit into the State of the Graph
Graph Engines is one of several interlocking categories in the broader State of the Graph map. Alongside it, we are building structured catalogs for graph databases, graph analytics, graph visualization, knowledge graphs, graph application development, and graph AI.
Each category has its own definition, inclusion criteria, and attributes, but they are designed to fit together. Graph engines in particular sit close to graph databases and graph analytics: they borrow concepts from both and give teams another option when moving everything into a new database is not realistic.
Help Us Pressure-Test the Graph Engines Catalog
This is a first version, not the final word. The boundaries between graph engines, databases, analytics frameworks, and visualization tools are still evolving, and we fully expect to refine this category as the community weighs in.
We would especially like feedback on questions such as which engines you are actually deploying in production today, whether there are important graph coprocessors or virtualization layers we have missed, where our inclusion criteria feel right versus too strict or too loose, and whether there are engine capabilities such as security, multi-tenancy, or integration patterns you would like to see captured in future iterations.
If you build, operate, or evaluate graph engines — whether as an engineer, architect, data scientist, product owner, or vendor — your input will help us sharpen this map.
Explore the Graph Engines catalog and tell us what we should add, refine, or reclassify. Your feedback will shape not only the next version of this category, but also how graph engines connect with the rest of the State of the Graph.
Leave a Reply