Built for graphs from the ground up

Like many open source projects and open source NoSQL database management systems, Neo4j came into existence for very specific reasons. Scratching the itch, as this is sometimes called. Grassroots developers who want to solve a problem and are struggling to do so with traditional technology stacks decide to take a radical, new-found approach. That's what the Neo4j founders did early in the 21st century--they built something to solve a problem for a particular media company in order to better manage media assets.

In the early days, Neo4j was not a full-on graph database management system; it was more like a graph library that people could use in their code to deal with connected data structures in an easier way. It was sitting on top of traditional, MySQL, and other relational database management systems, and was much more focused on creating a graph abstraction layer for developers than anything else. Clearly, this was not enough. After a while, the open source project took the radical decision to move away from the MySQL infrastructure and build a graph store from the ground up. The key thing here is from the ground up. The entire infrastructure, including low-level components such as the binary file layout of the graph database store files, is optimized to deal with graph data. This is important in many ways, as it will be the basis for many of the speed and other improvements that Neo4j will display versus other database management systems.

We don't need to understand the details of this file structure for the basis of this book, but suffice it to say that it is a native, graph-oriented storage format that is tuned for this particular workload. This makes a big difference.