# Neo4j Server vs Embedded
---

[TOC]

## Usage modes overview

When Neo4j was first released, it was aimed squarely at the Java-based world, and back then it only supported the **embedded mode**. Within the embedded mode setup, your Java application and new shiny Neo4j database were happily bundled together as a single deployable entity, and together they went forth to conquer the brave new world of interesting graph-based problems.


In embedded mode, Neo4j can be used by any client code that’s capable of running within a JVM. As figure 10.1 illustrates, you can use the embedded mode directly b
with pure Java clients, which make direct use of the core Neo4j libraries, or indirectly,
through additional language-specific bindings and frameworks c provided by various
communities for other JVM-based languages.
In server mode, client code interacts with the Neo4j server via the HTTP protocol,
specifically via a well-defined REST API, with additional options being available to
extend this REST functionality when required. The API can be used directly by any
HTTP-enabled client d, or, to make development life a little easier, by using one of
the remote REST client APIs available for a variety of different languages and frameworks e. With the inherent network latency introduced in the server mode, performance is naturally not going to be as good as accessing the database using native code
directly. To add more flexibility to the server offering, server plugins and unmanaged
extensions f can also be used to bolster performance and functionality. We’ll be covering server plugins and extensions later in this chapter.

## Advantages and disadvantages

|Server type| Advantages| Disadvantages|
|---|---|---|
|Embedded| Speed. |Language restrictions (only Java and JVM languages supported).|
||Ability to take full advantage of all low-level APIs directly.| Possible common library clashes with your application.|
|| Ability to operate in HA setup.| Tight coupling of application process and Neo4j.|
|||Application may potentially impact the database’s performance and vice versa.|
||| Inability to scale Neo4j independently of the application.|
|Server| Decoupled architecture: you can scale and manage Neo4j independently of the application.| Awkward and cumbersome fine-grained REST API. |
| | Larger set of client platforms supported (not only JVM-based). | Slower speed, though using REST streaming, Cypher, batching, server plugins, and extensions may help.
| | Multiple clients can use the database. | Restricted to only being able to deal with JSON or HTML responses for raw REST API at this point in time.
|| Ability to operate in HA setup.||

## Architectural considerations

The server mode can cater to a much larger set of client platforms compared to the embedded mode. With the embedded mode, you’re restricted to Java or one of the other supported JVM-based languages only; the server mode can deal with any client that can “talk” HTTP


With the embedded mode, the lifecycle, memory, and processing capabilities of
the application (social-movie.war) are tightly bound to those of the embedded Neo4j
database; with the server mode, there are separate JVMs handling the application and
the Neo4j database (JVM 1 and JVM 2). In the server version, the administration application is separated out into its own PHP-based web client, even further decoupling the
main components and applications from one another.
In embedded mode, your application and Neo4j share the same JVM and therefore
share the same Java heap; they’re subject to the same garbage collection (GC) cycle and will essentially live and die together. If your application causes or triggers GC in
embedded mode, this may impact the performance of Neo4j. What may appear to be
Neo4j reacting slowly may simply be Neo4j waiting for a GC pause to complete. There
may also be cases when you’ll want to tune the Neo4j JVM and GC parameters separately from those of your application, as they may have fundamentally different usage
patterns. Unfortunately, this isn’t possible with embedded mode

## Performance considerations

Performance is one of the key areas where the embedded and server modes differ.
Neo4j in embedded mode will always outperform the server mode when doing a
direct comparison of execution times for the same set of operations done via the
native Java API as opposed to the REST API. This is due to the added latency and overhead associated with making calls over the network.
By way of an initial comparison, look at the results detailed in table 10.2, showing
the time in milliseconds for embedded and server modes (with nodes per second in
parentheses) taken to create one million new user nodes with a name property. Each
new node was created in its own transaction (TX) using the raw Java API in embedded
mode versus the raw REST API of the server mode.



## Summary

With the embedded mode, you have quite a cozy relationship with Neo4j, which is
only available to Java and a select number of other JVM-based languages. Though you
get direct access to all of Neo4j’s low-level APIs and can leverage the performance
gains associated with this, you’re also required to share your resources (memory and
the like) with Neo4j as well. This could potentially introduce additional overhead
and complications to the management of your application, and that needs to be
taken into account.
In the server mode, the Neo4j process is isolated and can be managed completely
separately from that of the application, which is a big win in large distributed architectures. All the interactions, however, need to be done through the REST abstraction
layer, which although it casts a wider net in terms of the clients it supports, has some
performance implications that need to be understood and dealt with appropriately.big

## Refer

- Neo4j in Action: https://www.oreilly.com/library/view/neo4j-in-action/9781617290763/