This is the manual for the official Neo4j JDBC Driver.
The Neo4j JDBC Driver is in Early Access Preview (EAP) and might break unexpectedly. Being in EAP means that you have the opportunity to provide feedback on the implementation of the driver. The functionality and behaviour released in the GA release may differ from those available in the EAP. This driver is officially supported and endorsed by Neo4j. It is a standalone driver, independent of and not built on top of the common Neo4j Java Driver. While the latter provides a Neo4j-idiomatic way to access Neo4j from Java, the JDBC driver adheres to JDBC 4.3.
<dependency>
<groupId>org.neo4j</groupId>
<artifactId>neo4j-jdbc-full-bundle</artifactId>
<version>6.0.0-M03</version>
</dependency>dependencies {
implementation 'org.neo4j:neo4j-jdbc-full-bundle:6.0.0-M03'
}All releases from 6.0 onwards contain a zipped version of the driver, including a PDF version of the manual. We offer several distributions, please have a look here for more details. If you feel adventurous, grab the code and build the driver yourself. You find the instructions in our contribution documentation.
The JDBC acronym stands for "Java Database Connectivity" and as such is not bound exclusively to relational databases. Nevertheless, JDBC is highly influenced by the SQL standard and existing, relational databases, in regard to terms, definitions and behaviour defined. Neo4j is a graph database with quite a different paradigm than relational and a non-standardized behaviour in some areas. There might be some details that don’t map 100% in each place, and we make sure to educate you about these in this documentation
|
Note
|
Inside this documentation we will refer to this driver as the Neo4j JDBC Driver and to the idiomatic Neo4j driver as the common Neo4j Java Driver. |
The Neo4j JDBC Driver requires JDK 17 on the client side and a minimum version of Neo4j 5.5 on the server side. To use it against a Neo4j cluster, server-side routing must be enabled on the cluster.
-
JDK 17 baseline
-
Fully supports the Java module system
-
Adheres to JDBC 4.3
-
Can run any Cypher statement
-
Implements
DatabaseMetaDataandResultSetMetaDataas fully as possible with a nearly schemaless database and general very flexible result sets, allowing for automatic metadata retrieval from ETL and ELT tools -
Provides an SPI to hook in translators from SQL to Cypher
-
Provides an optional default implementation to translate many SQL statements into semantically similar Cypher statements
-
Can be safely used with JDBC connection pools as opposed to the common Neo4j Java Driver or any JDBC driver based on that, as it doesn’t do internal connection pooling and transaction management otherwise than dictated by the JDBC Spec
The absence of any connection pooling and transaction management is actually an advantage of the Neo4j JDBC Driver over the common Neo4j Java Driver. It allows to pick and choose any database connection pooling system such as HikariCP and transaction management such as Jakarta Transactions.
|
Note
|
The default SQL to Cypher translation implementation is based on jOOQ by Datageekery. We are a long-time fans of how Lukas Eder—inventor of jOOQ—has bridged the gap between Java and database querying. It even inspired the Cypher-DSL, providing the other half of our translation layer. We are grateful for kick-starting the original Sql2Cypher project together in early 2023, on which we can build now. |
-
The database metadata is retrieved on a best effort base, using existing schema methods of Neo4j, such as
db.labels,db.schema.nodeTypeProperties() -
While single label nodes map naturally to table names, Nodes with multiple labels don’t
-
There is no reliable way to always determine the datatype for properties on nodes without reading all of them (which this driver does not do)
-
Some JDBC features are not yet supported (such as the
CallableStatement), some feature won’t ever be supported -
The SQL to Cypher translator does only support a limited subset of clauses and SQL constructs that can be semantically equivalent translated to Cypher (See [s2c_supported_statements])
-
There is no "right" way to map
JOINstatements to relations, so your mileage may vary
This driver has been developed with the following use-cases in mind:
-
Integration with ETL and ELT tools that don’t offer an integration based on the common Neo4j Java driver
-
An easier on-ramp towards Neo4j for teams that are familiar with JDBC and want to keep on using that API, but with Cypher and Neo4j
-
Integration for ecosystems like Jakarta EE whose transaction management will directly support any compliant JDBC driver
-
Integration with database migration tools such as Flyway
There is no need to redesign an application that is build on the common Neo4j Java Driver to use this driver. If your ecosystem already provides a higher-level integration based on the common Neo4j Java Driver, such as Spring Data Neo4j (SDN) for Spring, there is no need to switch to something else. In case of Quarkus the Neo4j JDBC Driver is an option to consider: While we do provide an integration for the common Neo4j Java Driver, this integration does not support Quarkus' transaction systems in contrast to this driver.
While there is little incentive to use this driver with Hibernate (Neo4j-OGM or SDN are the better alternatives for Neo4j), it might be worth giving Spring Data JDBC a try.
Several other JDBC drivers exists for Neo4j, most notably the previous versions 4 and 5 of this driver, originally developed by Larus BA, Italy for Neo4j. Most—if not all of them—do wrap the common Neo4j Java Driver and implement the JDBC spec on top of that. This comes with a bunch of problems:
-
The common Neo4j Java Driver manages a connection pool; JDBC drivers on the other hand delegate this task to dedicated pooling solutions: If you take the above-mentioned driver into a standard container, you will eventually end up with a pool of pools
-
The transaction management of the common Neo4j Java Driver is not exactly aligned with the way JDBC thinks about transactions, it’s usually hard to get this exactly right
-
Additionally, the original JDBC driver from Larus shades a couple of dependencies, such as Jackson as well as additional logging frameworks which takes a toll on the classpath and in case of logging, does actually lead to runtime problems
-
Existing drivers with a SQL to Cypher translation layer are "read-only" and don’t support write statements
There are some drivers available that provide a SQL to Cypher translation layer as well. Those however are read-only and cannot be used for ETL use-cases aiming to ingest data into Neo4j.
One feature that this driver does not provide is automatic reshaping or flattening of the result-sets, as the previous incarnation does:
If you query for objects such as nodes, relationships, paths or maps you can and should use getObject on the result-sets and cast to the appropriate type (you find all of them inside the package org.neo4j.jdbc.values).
However, the default SQL to Cypher translator will—when connected to a database—figure out what properties labels have and turn the asterisk (*) into individual columns of nodes and relationships, just like what you would expect when running a SELECT * statement.
![dependabot[bot] avatar](https://avatars.githubusercontent.com/in/29110?v=4 "dependabot[bot]")
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent