Gremlin vs Cypher: Key Differences

Gremlin and Cypher are two of the most established query languages for the labeled property graph. Both target the same data model of nodes and relationships with properties on each, and both are supported by well-known graph systems, yet the way they express a query is almost opposite. Gremlin is a traversal language from Apache TinkerPop: a query is a step-by-step description of how to walk the graph. Cypher is a declarative pattern-matching language originally from Neo4j and a major influence on ISO GQL: a query is a picture of the shape you want, drawn once and left to the optimizer.

That paradigm split is the real subject of any comparison between them, more so than syntax. This post explains each language on its own terms, walks through the differences that matter in practice, offers a framing for when to reach for each one, and covers how the two coexist in systems that support both.

What is Gremlin?

Gremlin is the graph traversal language of Apache TinkerPop, an Apache Software Foundation top-level project that defines a common API and reference implementation for graph systems. A Gremlin query is a chain of steps, each consuming a stream of graph elements from the previous step and emitting the elements that meet its condition. V() starts at all vertices, has('Person', 'name', 'Alice Chen') narrows to one, out('KNOWS') moves along outgoing KNOWS edges to their targets, and so on. The chain reads as a plan for walking the graph, not as a description of a shape.

The same question used in the SPARQL vs Cypher post, finding Alice’s friends and the organizations they work for, looks like this in Gremlin:

g.V().has('Person', 'name', 'Alice Chen')
  .out('KNOWS').as('friend')
  .out('WORKS_FOR').as('org')
  .select('friend', 'org').by('name')

g is the traversal source from which a traversal typically starts. V() reads vertices, and has(...) narrows them by label or property. Each out(label) step follows outgoing edges of the given label to their end vertices. as('friend') and as('org') tag intermediate positions in the walk, and select(...).by('name') reaches back into those tags to pull out the properties for the result. Longer traversals stack the same primitive shapes: repeat(out()).times(3) walks three hops of outgoing edges, and path() returns the sequence of elements the traversal touched.

Gremlin is defined by TinkerPop rather than by one storage engine. Familiar TinkerPop-compatible systems include TinkerGraph, JanusGraph, Amazon Neptune, and Azure Cosmos DB’s Gremlin API. Their supported features and execution strategies differ, but they share the same traversal model and core language.

What is Cypher?

Cypher is a declarative query language for the labeled property graph, in which nodes carry labels, relationships carry a type, and both carry key-value properties. Neo4j created the language and shipped it in 2011; in 2015 the company opened the specification as openCypher, and implementations now exist well beyond Neo4j, including Memgraph and Amazon Neptune. Cypher’s syntax is built around drawing the pattern you want: nodes are parentheses, relationships are arrows, and a path reads like ASCII art of the graph itself.

The same query in Cypher:

MATCH (alice:Person {name: 'Alice Chen'})-[:KNOWS]->(friend:Person)
      -[:WORKS_FOR]->(org:Organization)
RETURN friend.name, org.name

Where Gremlin walks the graph step by step, Cypher declares the pattern to find. The MATCH clause draws the shape, WHERE (when present) filters it, and RETURN projects the result. The engine’s optimizer decides which anchor to start from, which edges to traverse first, and how to combine intermediate results. Variable-length paths handle reachability (-[:KNOWS*1..3]-> matches chains of one to three hops), and the language includes aggregation, OPTIONAL MATCH for outer-join semantics, and write clauses (CREATE, MERGE, SET, DELETE), so one language covers both reads and updates.

Cypher began as one vendor’s language, spread through openCypher, and became a major influence on ISO GQL. That gives Cypher an open specification and, through GQL, a standards trajectory beyond any one implementation.

Gremlin vs Cypher: key differences (table)

Because both languages target the same data model, the differences below sit at the paradigm and ecosystem levels rather than at the model level.

 Query paradigm. Gremlin describes the walk: each step in a traversal consumes a stream of elements and emits the next. Gremlin also allows a declarative form built from pattern steps, but the step chain is the idiom it is written and reasoned about in. Cypher describes the shape: a query is a pattern, and the planner decides how to find every occurrence of it. Gremlin makes each stage of the traversal visible to the author, while Cypher gives the planner a complete pattern to work from.

Syntax shape. A Gremlin traversal is a method chain (g.V().has(...).out(...).values(...)); a Cypher query is drawn like an annotated graph diagram ((a)-[:KNOWS]->(b)). Cypher is often easier to scan as a visual pattern. Gremlin maps directly onto a step-by-step mental model of the walk.

Standardization. Gremlin is governed by Apache TinkerPop, which publishes a reference implementation and a grammar rather than a separate language specification. Cypher originated at Neo4j, was opened through openCypher, which publishes a language specification, and influenced ISO GQL. Both are defined in the open, but their governance and standards paths differ.

Engine coverage. Support depends on the engine. TinkerPop-compatible systems include JanusGraph, Neptune, Cosmos DB, and TinkerGraph. Neo4j originated Cypher, and openCypher implementations include Memgraph and Neptune. Neptune supports both, which shows that picking a language and picking an engine are separate decisions.

Updates and analytics. Both languages read and write, and the difference is the form the write takes. Cypher adds dedicated write clauses (CREATE, MERGE, SET, DELETE) alongside MATCH; Gremlin adds mutation steps (addV, addE, property) that sit in the traversal chain like any other step. Graph algorithms and analytical extensions vary by engine rather than by language alone.

The table reads as a division of strengths, not a ranking. The paradigm split, together with the ecosystem the paradigm grew up in, is what makes the choice consequential. Which side fits a team depends less on the language itself than on how the team likes to think about traversals, and the two sections below take each in turn.

When to choose Gremlin

Choose Gremlin when the target platform or the workload pushes you toward TinkerPop.

The clearest case is engine coverage. If a project is standardizing on JanusGraph, Azure Cosmos DB’s Gremlin API, or another TinkerPop-compatible system, Gremlin is the language the engine speaks first, and openCypher may not be available. Even where both are offered, a team already committed to TinkerPop tooling and a large Gremlin codebase has little reason to introduce a second language.

The other case is how the team reasons about a traversal. Gremlin makes the sequence of navigation, filtering, and branching explicit, which suits engineers who prefer to build a query one stage at a time. Gremlin fits teams whose stack or engineering habits are already TinkerPop-shaped.

When to choose Cypher

Choose Cypher when readability and standardization weigh more than TinkerPop portability. The two supporting reasons are developer experience and the language’s standardization arc.

The most common driver is developer experience. Cypher’s pattern syntax resembles the graph diagram a team would draw before writing the query. Its declarative model also resembles SQL’s habit of stating the result and leaving the execution plan to the optimizer. This can make Cypher a natural fit when analysts, data scientists, and application engineers all need to read the same queries.

The other lever is standardization. Cypher strongly influenced GQL, and openCypher gives implementations a path toward the ISO standard. Teams that value that alignment can weigh it alongside the feature surface of the engine they plan to use.

Fitting Gremlin or Cypher into an existing data stack

Projects rarely adopt a graph language in isolation. The team already has SQL databases, a warehouse, or a lakehouse holding the entities and relationships that a graph query would traverse, and the real question is how either language fits alongside that infrastructure rather than whether the two graph languages coexist with each other. Most teams pick one graph language for a project and stay there; the harder decision is how it lands in the surrounding stack.

The classic route is the same for both languages. Stand up a dedicated graph store, build a pipeline that converts source records into vertices and edges, and keep the graph synchronized with the source. This provides a graph-native system and toolchain, but it also adds another data system, a copied dataset, and a synchronization pipeline. That architecture fits workloads where the graph is the system of record. When source tables remain authoritative, the recurring ETL and synchronization work become part of the adoption cost.

An alternative is to serve graph queries directly from the tables. PuppyGraph runs openCypher and Gremlin queries directly over existing tables in SQL databases, data warehouses, and data lakes / lakehouses, including direct reads of open table formats like Iceberg and Delta Lake, with no ETL into a graph store. A user-defined schema maps tables to nodes and edges, and queries compile into a plan of node and edge operators that runs in its own distributed engine, letting it optimize specifically for multi-hop traversals. The choice between Gremlin and Cypher then reduces to a language preference for the team writing the queries rather than a commitment to a particular graph database, and because the engine speaks openCypher over the Bolt protocol, existing Neo4j drivers and tools can be repointed without rewriting queries.

Conclusion

Gremlin and Cypher both query the labeled property graph, and beyond that they differ in almost every dimension that shapes daily use: Gremlin is a step-by-step traversal chain under Apache TinkerPop, Cypher is a declarative pattern match converging on ISO GQL. The right choice usually reduces to two questions. Which engine does the project already run on, or plan to run on, and how does the team think about writing a traversal, as a walk or as a shape. Once those are settled, the remaining decision is architectural rather than linguistic: whether the graph lives as a dedicated store fed by ETL, or as a queryable view over tables the team already operates.

Try the forever-free PuppyGraph Developer Edition and book a demo with the team to see how openCypher and Gremlin queries run over warehouse and lakehouse tables, with no graph-specific ETL, so the language choice stays a language choice and does not commit the project to a separate graph store.