Why We Have Chosen Gremlin Over GQL

One of the most critical decisions when building a new graph database is the query language. It’s the primary interface for developers, and the choice has long-lasting implications for usability, performance, and community adoption. At **YouTrackDB**, we’re frequently asked why we’ve invested so heavily in Apache TinkerPop’s Gremlin, especially with the rising popularity of GQL.

Our choice wasn’t just an adoption. It was the start of a collaboration. Here’s our thinking.

Gremlin’s Power: Flexibility and a Rich Ecosystem

From our perspective, Gremlin has several powerful advantages that make it a compelling choice for a modern database management system.

• A Responsive De Facto Standard: Surprisingly, the fact that Gremlin is a de facto standard, not a rigid ANSI standard, is one of its greatest strengths. This feature enables the TinkerPop project to respond quickly to community needs, incorporate modern changes in database development, and address any issues with the language rapidly.
• “Batteries Included” on the JVM: Gremlin can be a powerhouse for any database working on the JVM. It’s a language with “batteries included,” meaning we don’t have to implement complex query grammar from scratch. We can build on a mature, proven foundation.
• An IDE-Friendly DSL: Gremlin is a DSL-oriented (Domain-Specific Language) language. This feature makes it more IDE-friendly and composable than GQL. Developers can leverage the full power of their host programming language (such as Java, Groovy, or Python) to build queries programmatically, which is a significant advantage for complex applications.

Acknowledging the Hurdles

Despite these strengths, we’re also realistic. We are aware that Gremlin has weaknesses that can hinder newcomers.

• The Power of Standardization: Developers, especially in the database world, are accustomed to the benefits of a formal standard, such as SQL. A standard language guarantees stability, a massive pool of experienced developers, and a rich ecosystem of tools that “just work.”
• Learning Curve and Semantics: In AI-driven code generation, developers read documentation less and less. A query language must be intuitive at first glance. Some Gremlin’s operators and semantics can be misleading and verbose, and you should be acquainted with its imperative logic.
• Optimization Challenges: From a deep technical standpoint, Gremlin’s original imperative match() step has proven difficult for database providers to optimize and for users to use effectively.

Our Proposal: Merging Declarative GQL into Gremlin

Because of these challenges, we didn’t just choose Gremlin.

We decided to contribute to it.

The best way to solve the declarative vs. imperative debate is to unite them.

To that end, we proposed a new, declarative match() step to the Apache TinkerPop project, providing a concrete proposal to an idea that the TinkerPop Community has kept under consideration for some time.

The idea is simple but powerful: this new step accepts a query string from a standard declarative graph query language. The default language will be the GQL query language.

This approach enables an underlying database (such as **YouTrackDB*) to utilize its native query planner and optimizer to execute the complex pattern match efficiently. But here’s the magic: it integrates seamlessly* with the rest of Gremlin.

The match() step itself doesn’t return the data directly. Instead, all the variables bound in your MATCH clause (e.g., (c), (e), (p)) are automatically added to the traversal’s path history. You then use standard, imperative Gremlin steps like select() to access and continue processing that data.

Consider this example:

g.match("MATCH (c:Customer {name:'Andrii'})-[e:purchased]->(p:Product)")
.select("e")
.values("quantity")
.sum()

Here’s what happens:

1. match(“…”): The declarative GQL query finds all patterns of a customer named ‘Andrii’ who purchased a product. The database’s native optimizer handles this heavy lifting. The results c, e, and p are bound to the path history.
2. select(“e”): The Gremlin traversal continues, projecting the elements labeled e (the :purchased edges).
3. values(“quantity”).sum(): Standard, imperative Gremlin steps take over to operate on that stream of edges to sum up the quantity from each purchase, giving a total number of items bought.

Why Choose? The Best of Both Worlds

So, to answer the original question: “Why did we choose Gremlin over GQL?”

The truth is, we didn’t choose. We are actively working to merge Gremlin and GQL’s capabilities to create a single, powerful experience.

We aim to create an environment where every developer can choose their style.

You get GQL’s intuitive, declarative pattern-matching for finding complex relationships combined with Gremlin’s powerful, composable, and programmatic data manipulation.

You can blend the capabilities of both languages, all within a single query.