diff --git a/documentation/design/05-implementation.md b/documentation/design/05-implementation.md
index e861e0ce6a7c3896c4472ef1eb1ec5a946c74db7..85fff63c8e70b434f7c984b06cfb28308d1df562 100644
--- a/documentation/design/05-implementation.md
+++ b/documentation/design/05-implementation.md
@@ -71,6 +71,49 @@ There may be the potential need to store information beyond pure topologies,
 actually about network flows, i.e., information about a group of packets
 belonging together.
 
+### neo4j
+Due to the fact that network topologies, with all their elements and connections, 
+can be represented well by a graph, the choice of a graph database for persistence was obvious.
+After some initial experiments with RedisGraph, Neo4j was chosen, 
+because Neo4j allows the use of multiple labels (for nodes as well as edges) 
+and offers a wider range of plugins.
+
+The current implementation offers the possibility to persist different network elements 
+and their physical topology. It became clear that within the graph database one has to 
+move away from the basic idea of different independent graphs (topologies) and rather see 
+the whole construct as a single huge graph with a multitude of relations.
+
+The following figure shows our first idea of a persistence of network topologies with neo4j.
+
+```mermaid
+graph TD
+subgraph "representation in Database"
+PND[PND 1]
+A --> |belongs to| PND
+B --> |belongs to| PND
+C --> |belongs to| PND
+D --> |belongs to| PND
+E --> |belongs to| PND
+
+A[Node 1] --> |physical| B[Node 2]
+D[Node 4] --> |physical| B
+B --> |physical| C[Node 3]
+B --> |physical| E[Node 5]
+
+A --> |logical1| B
+B --> |logical1| C
+C --> |logical1| D
+D --> |logical1| E
+E --> |logical1| A
+end
+```
+
+The basic idea is to assign the different network elements to a specific Principal Network Domain (PND). 
+The different topologies are represented by a neo4j relationship between the network elements that are 
+stored as neo4j nodes. However, with this current variant it is not possible, as required in 
+[Topology Inventory](#topology-inventory), to represent topologies that are hierarchically 
+interdependent, since neo4j does not allow relations to be stored as properties (as described [here](https://neo4j.com/docs/cypher-manual/current/syntax/values/#structural-types)
+
 
 ## YANG to code