Search code examples
neo4j

neo4j scheme vs bolt scheme -- what is the difference, when should I use one over the other


I am setting up a neo4j aura database

I have a choice of two schemes:

  • neo4j+s://
  • bolt+s://

What are the similarities?

  • They both seem to have secured variations, using "encryption and full certificate checks against the system’s local CA store."
  • They both seem to support a ssc (self signed certificate) variation

What are the differences?

  • This page mentions neo4j scheme has "routing" whereas bolt does not
    • But this page mentions the bolt+routing scheme
    • How is "routing" relevant anyway, is routing only applicable when we talk about "clusters" of neo4j nodes vs "single instance" configurations (distributed among many servers, vs one server)?
  • The pages I can find on bolt say it is a "binary protocol over persistent TCP" suggesting it is "high-performance", is it better than neo4j scheme then?
    • Other pages say bolt can also operate over WebSocket connection
  • Some pages suggest "The neo4j:// scheme replaces bolt+routing:// and can be used for both clustered and single-instance configurations..."

connecting to an instance of neo4j hosted Aura, the user has the choice between neo4j+s and bolt+s schemes


Solution

    • bolt+routing is the ancestor of the neo4j scheme, in the 3.x version of Neo4j (where the +s and +ssc were specified through explicit configuration, not through the scheme)
    • neo4j, neo4j+s, neo4j+ssc imply (client-side) routing, the driver will regularly fetch routing information (initially from the target server) and route further queries appropriately
    • bolt, bolt+s, bolt+ssc means direct connection to the target server

    Before Neo4j 4, single server instances did NOT support the neo4j scheme, they would fail returning routing information. That is not true anymore, which is why using the neo4j scheme (or its variants thereof) is usually a good default since both single instances and clusters support it.

    Using the bolt scheme in a highly dynamic cluster environment is a BAD idea. The cluster topology can change pretty quickly. For instance, the initially targeted server may change from a leader to a follower role for a given database. When that happens, the server then starts to fail serving writes for that database.

    The neo4j scheme (or its variants) avoids this problem since the driver will keep an up-to-date view of the cluster topology and route queries accordingly.

    All official drivers supports Bolt over raw TCP. The JavaScript driver also supports Bolt over Websocket. The Go driver also supports Bolt over Unix sockets.