Database Support
Below is a list of all the graph databases supported by G.V(), along with how to connect to them and the specific features available on each.
| Database Name | Querying | Authentication Methods | Graph Data Explorer | Data Model Loading (via Schema API) | Data Model Loading (via data) | Schema View | Create/Update/Delete Vertices/Edges | Create/Update/Delete Properties | Query Profiling | Query Execution Plan |
|---|---|---|---|---|---|---|---|---|---|---|
| Aerospike Graph | Username/Password | |||||||||
| AllegroGraph | Username/Password | |||||||||
| Amazon Neptune | AWS IAM Credentials:
| |||||||||
| Amazon Neptune Analytics | Same as Amazon Neptune | |||||||||
| Apache AGE | Username/Password | |||||||||
| Apache Jena Fuseki | Username/Password | |||||||||
| ArcadeDB | Username/Password | |||||||||
| Azure Cosmos DB | Azure Cosmos DB Auth Key | |||||||||
| Blazegraph | Username/Password | |||||||||
| DataStax Enterprise Graph | Username/Password | |||||||||
| Dgraph | Username/Password | |||||||||
| Eclipse RDF4J | Username/Password | |||||||||
| FalkorDB | Username/Password | |||||||||
| Google Cloud BigQuery Graph | gcloud CLI Application Default Credentials (ADC) | |||||||||
| Google Cloud Spanner Graph | gcloud CLI Application Default Credentials (ADC) | |||||||||
| GraphDB | Username/Password | |||||||||
| Gremlin Server | Username/Password | |||||||||
| JanusGraph | Username/Password | |||||||||
| Kuzu | N/A | |||||||||
| LadybugDB | N/A | |||||||||
| LocalStack Amazon Neptune | N/A | |||||||||
| Memgraph | Username/Password | |||||||||
| Neo4j | Username/Password | (APOC Library required) | ||||||||
| Neo4j AuraDB | Username/Password | (APOC Library required) | ||||||||
| Oracle Graph | Username/Password | |||||||||
| PuppyGraph | Username/Password | |||||||||
| QLever | Bearer Token (UPDATE only) | |||||||||
| RDFox | Username/Password | |||||||||
| RyuGraph | N/A | |||||||||
| Stardog | Username/Password | |||||||||
| Aliyun's Tair图引擎 (Tair for Graph) | Username/Password | |||||||||
| Tentris | Username/Password | |||||||||
| Ultipa Graph | Username/Password | |||||||||
| Virtuoso | Username/Password | |||||||||
| Other RDF Triplestores | Username/Password |
Aerospike Graph
G.V() is fully compatible with Aerospike Graph.
Connecting G.V() to your Aerospike Graph Database is quick and easy. Before you start, make sure your Aerospike Graph database is up and running following instructions at https://docs.aerospike.com/graph/docker/getting_started.
If you are running your Aerospike Graph Database from a networked device, make sure that the machine you're running G.V() from can connect to the device.
TIP
Sign up for a free, no obligation 60 days G.V() trial to match your Aerospike Graph trial!
First, download and install G.V().
Then, connect your Aerospike Graph database as shown above.
You will be prompted for basic details after setting up your connection. Once you submit your contact details, you will be automatically enrolled into a free, no obligation 60 days trial.
For more details on what you can do with Aerospike Graph and G.V(), check out our introduction video below:
AllegroGraph
G.V() is fully compatible with AllegroGraph.
Amazon Neptune
G.V() is has been tested for compatibility with Amazon Neptune Server Engine 1.0.4.2 and above, though it should also be compatible with older versions as well. Additionally, when performing explain/profile queries, G.V() will automatically leverage the Neptune explain/profile APIs to provide the Amazon Neptune native output of these steps. G.V() provides direct integrations with several other Amazon Neptune specific features such as Slow Query Logs. G.V() supports both the Gremlin and Cypher querying languages for Amazon Neptune.
Amazon Neptune Analytics
G.V() is fully compatible with Amazon Neptune Analytics since its first release. We support both the Gremlin and Cypher querying languages for Amazon Neptune Analytics.
Apache AGE
G.V() is fully compatible with Apache AGE and can be queried using Cypher queries directly or SQL. When writing a Cypher query, G.V() will automatically wrap it in a SELECT * FROM cypher(<graph_name>, $$ <cypher_query> $$) as (...), allowing you to access our full Cypher autocomplete and syntax validation functionality. Cypher queries on Apache AGE in G.V() also supports injecting parameters, and will automatically submit them.
Apache Jena Fuseki
G.V() is fully compatible with Apache Jena Fuseki.
ArcadeDB
G.V() is fully compatible with ArcadeDB version 22.1.3 and above but should function equally well with earlier versions.
G.V() connects to ArcadeDB using the Gremlin Server endpoint. Make sure the Gremlin Server plugin is enabled on your ArcadeDB instance by following the instructions under "Use the Gremlin Server" at https://docs.arcadedb.com/#gremlin-api.
Azure Cosmos DB
G.V() is fully compatible with Azure Cosmos DB's Gremlin API. This includes the Azure Cosmos DB Emulator.
Blazegraph
G.V() is fully compatible with Blazegraph.
DataStax Enterprise Graph
G.V() is fully compatible with DataStax Enterprise Graph's classic and core implementations, though for the optimal experience we recommend using the core graph version.
Dgraph
G.V() is fully compatible with Dgraph v22.0.2 and above. Syntax validation and autocomplete for DQL queries is not currently supported, but will be introduced in a later release. G.V() supports sending DQL queries, and N-Quads mutations to Dgraph.
Eclipse RDF4J
G.V() is fully compatible with Eclipse RDF4J.
FalkorDB
G.V() is fully compatible with FalkorDB v4.0.2 and above.
Google Cloud BigQuery Graph
G.V() is compatible with Google Cloud BigQuery Graph, with a few features not currently available:
- Create, update and delete graph Elements interactively
- Syntax validation and autocomplete for GoogleSQL queries
- Ability to specify query parameters (e.g. @my_param) and their values directly in the user interface
- Ability to generate GoogleSQL queries via LLMs
- GoogleSQL queries on G.V() currently run in read-only mode
You can use both the GoogleSQL and GQL/PGQL languages to query your BigQuery Graph instance, as defined in the official Spanner documentation
Creating Graph Visualizations from GoogleSQL Queries
Google Spanner Graph does not currently support returning raw Graph Element types (Node, Edge, Path) in GoogleSQL queries. To allow returning these types in a query, they must be wrapped with either the TO_JSON or TO_SAFE_JSON function. By translating values to JSON, they can be safely returned by Spanner Graph, and interpreted as Graph Elements by G.V(), leading to a graph visualization. See example query below:
GRAPH TransitGraph
MATCH p=(src:Station{name: "Bond Street"})-[r:ROUTE]->{1,7}(dest:Station{name: "Westminster"})
-- Wrapping p in RETURN statement with SAFE_TO_JSON to allow it to be returned as a JSON object
RETURN src.name AS Start, ARRAY_LENGTH(r) AS stops, dest.name AS Dest, SAFE_TO_JSON(p) as path
ORDER BY stops LIMIT 4Google Cloud Spanner Graph
G.V() is compatible with Google Cloud Spanner Graph, with a few features not currently available:
- Create, update and delete graph Elements interactively
- Syntax validation and autocomplete for GoogleSQL queries
- Ability to specify query parameters (e.g. @my_param) and their values directly in the user interface
- Ability to generate GoogleSQL queries via LLMs
- GoogleSQL queries on G.V() currently run in read-only mode
You can use both the GoogleSQL and GQL/PGQL languages to query your Spanner Graph instance, as defined in the official Spanner documentation
GraphDB
G.V() is fully compatible with GraphDB.
Gremlin Server
At minimum, your Gremlin Server must be running Apache TinkerPop™ 3.4.0.
JanusGraph
G.V() is compatible with JanusGraph versions 0.5.0 and above, as well as JanusGraph 1.x.
TIP
G.V() uses JanusGraph driver v0.6 and does not currently support GraphBinary serialization for 1.0. By default G.V() uses GraphSON v3 serialization for JanusGraph to ensure compatibility across multiple JanusGraph versions.
Kuzu
G.V() is fully compatible with Kuzu and is currently using Kuzu version 0.11.3. If using a previous version of Kuzu, please export your dataset and reimport it in G.V() following the instructions in the section just below.
Migrating Kuzu versions
G.V() tracks the latest version of Kuzu, meaning that the storage version of your dataset should match the storage version used by Kuzu in G.V().
To perform a migration to the latest version of Kuzu, follow the instructions at https://docs.kuzudb.com/migrate/.
If you are migrating from Kuzu <= 0.10.0 to Kuzu >= 0.11.0, you will also need to reconfigure your Kuzu database configuration to specify the file path of your Kuzu storage as opposed to its folder path. To do so, edit your connection and enter your new file path, or directly drop the file on the Select your Kuzu database file path or drop it here input, then click on Submit.
LadybugDB
G.V() is fully compatible with LadybugDB and is currently using LadybugDB version 0.12.0. If using a previous version of LadybugDB, please export your dataset and reimport it in G.V() following the instructions in the section just below.
Migrating LadybugDB versions
G.V() tracks the latest version of LadybugDB, meaning that the storage version of your dataset should match the storage version used by LadybugDB in G.V().
To perform a migration to the latest version of Kuzu, follow the instructions at https://docs.ladybugdb.com/migrate/.
LocalStack Amazon Neptune
G.V() is fully compatible with all engine versions available on LocalStack's Amazon Neptune image.
Memgraph
G.V() is compatible with Memgraph v2.0 and above.
Neo4j and Neo4j AuraDB
G.V() is compatible with Neo4j and AuraDB instances running on version 4.4 and above.
Oracle Graph
G.V() is compatible with Oracle Graph on Oracle 23ai, using the SQL:2023 language variant. There are a few features not currently available:
- Create, update and delete graph Elements interactively
- Syntax validation and autocomplete for SQL:2023 queries
- Ability to specify query parameters (e.g. ? or :var1 and their values directly in the user interface)
- Ability to generate SQL:2023 queries via OpenAI
You can use both the GoogleSQL and GQL/PGQL languages to query your BigQuery Graph instance, as defined in the official Spanner documentation
Creating Graph Visualizations from SQL:2023 Queries
Oracle Graph does not currently support returning raw Graph Element types (Node, Edge, Path) in SQL:2023 queries. To allow returning these types in a query, you must return their vertex and edge ids instead, using the vertex_id and edge_id functions in the query's columns statement. This allows us to retrieve the full graph elements from the database, and render them into a graph visualization. See example query below:
Select * from
graph_table(
OGB_SOCIAL_GRAPH Match (n) -[e]-> (m)
Columns(vertex_id(n) as nid, edge_id(e) as Eid, vertex_id(m) as mid)
)
FETCH FIRST 1000 ROWS ONLYPuppyGraph
G.V() is fully compatible with PuppyGraph versions 0.5 and above. G.V() is also compatible with PuppyGraph 0.2, 0.3 and 0.4 but will not accurately detect that the database is readonly. G.V() requires your PuppyGraph credentials to connect to their schema API which allows our software to instantly fetch your PuppyGraph's data model. G.V() supports both the Gremlin and Cypher querying languages for PuppyGraph
WARNING
PuppyGraph is a readonly Graph database meaning that certain operations such as editing vertices/edges is not (currently) supported. We're actively monitoring opportunities for write operations to be introduced in PuppyGraph and will update G.V() accordingly.
QLever
G.V() is compatible with QLever, and UPDATE operations are now supported directly within G.V(). QLever uses a Bearer token (typically configured in the QLeverfile) to authorize UPDATE queries. You can supply this token by placing it in the Connection’s password field. Keep in mind that SAPRQL UPDATE capability in QLever is still experimental and under active development.
RDFox
G.V() is fully compatible with RDFox datastores. According to their official documentation, RDFox provides full support for the SPARQL 1.1 query language, with two exceptions: the BNODE function variant that takes a single string argument, and the non-normative DESCRIBE query form. The default RDFox datastore type in RDFox, query-validation, applies non-standard constraints by rejecting queries that project variables not referenced in the WHERE clause. This deviation from standard SPARQL may interfere with parameterized queries, where injected parameters can cause projected variables to become absent from the query body. If you use query-validation datastores, please be aware your query might be rejected in some parameter injection cases.
RyuGraph
G.V() is fully compatible with RyuGraph and is currently using RyuGraph version 25.9.1. If using a previous version of RyuGraph, please export your dataset and reimport it in G.V() following the instructions in the section just below.
Migrating RyuGraph versions
G.V() tracks the latest version of RyuGraph, meaning that the storage version of your dataset should match the storage version used by RyuGraph in G.V().
To perform a migration to the latest version of RyuGraph, follow the instructions at https://ryugraph.io/docs/migrate/.
Stardog
G.V() is fully compatible with Stardog.
Aliyun's Tair图引擎 (Tair for Graph)
G.V() is fully compatible with Aliyun's Tair图引擎 Database.
Tentris
G.V() is fully compatible with Tentris.
Ultipa Graph
G.V() is fully compatible with Ultipa Graph using the Graph Query Language (GQL)
Virtuoso
G.V() is fully compatible with Virtuoso. Please note that OpenLink Virtuoso enforces strict limitations on SPARQL UPDATE operations over the default graph. You must either grant appropriate write privileges to the SPARQL user or explicitly target a named graph in all UPDATE queries. If you rely on the default graph instead, certain visual vertex and edge manipulation operations may be rejected.
Other RDF Triplestores
For any RDF triplestore not officially supported by G.V(), select the RDF (Other) option. SPARQL read operations (SELECT, ASK, CONSTRUCT, DESCRIBE) will function correctly as long as the endpoint adheres to W3C standards for RDF and SPARQL. For UPDATE operations, if your triplestore uses a different endpoint for write queries than for read queries, you may need to adjust the endpoint manually in the Edit Connection section.