Why we use Neo4j for custom business software

Neo4j's strength starts with a very simple model. A piece of data is a node. A relationship connects two nodes. Both nodes and relationships can carry properties. A label then classifies a node as a Customer, a Product, a User, a Contract, a Step, a Document, an Organisation or a Permission.

Technically a node stays a node. It is not a fixed table. It can have no label, one label or several. It can also change over time. The same node can be a Person, a Contact, an Administrator and an Actor in a business process all at once. That freedom is very powerful because it lets us model reality without squeezing it too early into a rigid structure.

But that freedom becomes dangerous without method. A graph with no rules quickly turns unreadable. Too many labels, vague relationships, properties placed at random and concepts that overlap. So we keep the flexibility of Neo4j and build a strict model on top of it. Label names, relationship types and directions, mandatory properties, constraints and indexes are all defined. So are the rules for reading the graph and the rules for changing it.

We rely a lot on polymorphism in our software. The word sounds abstract but the idea is simple. Several different objects can be handled with shared logic because they share a behaviour, an interface or a basic structure.

Take a User, a Company, a Site, a Document or a Task. They are very different business objects. Yet they can all be linked, kept with their history, given access rules, shown in a tree, attached to a project or covered by a workflow rule. Polymorphism lets us write generic logic for those behaviours instead of copying the same code for each type of object.

Neo4j fits this way of thinking very well. A node can represent different things and its labels give it its roles. That lets us build generic structures that last and that can repeat at any depth. An organisation can contain teams, which contain people, who hold permissions, which apply to projects, which contain sub-projects of their own. We can walk through that structure without reinventing a join or a link table at every level.

Many businesses are not flat. A company has subsidiaries, branches, teams, roles and exceptions. A product can be made of sub-products. A building project can contain phases, work packages, interventions and then inspections. A process can have steps, then sub-steps, then conditions for moving on.

That is what we call a recursive structure. Something can contain something of the same type or of a close family. In a classic relational database these models often get heavy to maintain. You end up multiplying tables, foreign keys, special cases and complex queries.

In Neo4j we can represent that logic much more naturally. We no longer only ask which row sits in which table. We ask through which paths a piece of data is connected to the rest. That is often where the graph becomes very efficient.

Another big advantage of Neo4j is not technical. It is about explaining. When we work with a client we can show the model as bubbles and links. Here is a Customer, here a Contract, here a Site, here an Intervention. And here is the link that says this intervention depends on this site and this contract.

Even someone with no technical background can then join the discussion. They can tell us this link is wrong, this information belongs on the relationship, this rule really belongs to the step or this notion should exist on its own. We do not ask them to understand a database. We show them how their business is structured.

This phase matters a great deal to us. It lets us rebuild business knowledge properly before building the screens. It avoids software that works technically but describes the company badly. A good data model is often what separates fragile software from software that can grow. We explain this step in more detail in our article on modelling business data first.

The diagrams below are deliberately simplified. The bubbles are nodes, in other words business objects. The arrows are typed relationships. Items in curly braces are properties stored on the relationship when they describe the link itself.

This format is very handy in a client workshop. We can point at a bubble, point at an arrow and decide together whether the information is in the right place. That is where Neo4j becomes very concrete.

Neo4j gives a lot of freedom. That is exactly why we have to be strict. In our projects we never let the graph fill up at random. We define the concepts, labels, relationships, properties and invariants. We decide what should be a node, what should be a relationship and what should simply be a property.

That decision is fundamental. If a piece of information has its own identity, if it must be linked to several objects, kept with its history, filtered, shared or queried on its own, it often deserves to be a node. If it only describes a simple state, it can stay a property. If it qualifies the link between two things, it may belong on the relationship.

This discipline lets us use Neo4j for rich engineering without ending up with a mess. The model stays readable and easy to audit as it evolves.

Our goal is not only to get the first version working. We prepare the data so the software holds up over time. Businesses change, teams change, permissions change and user journeys change. A model that is too closed often forces you to break the structure after a few months.

With a well framed graph approach we can absorb those changes better. We can add a new type of relationship, a new role, a new level in a hierarchy or a new business rule without rebuilding everything. The software stays alive and its model stays understandable.

That is why we like Neo4j on some custom software projects. It lets us design systems that respect the complexity of the business while keeping a clear architecture.

Neo4j is not the right choice for every piece of software. If the need is a simple CRUD app, a classic catalogue or very standard reporting, a relational or document database may suit better. The right technical choice is the one that serves the problem, not the one that looks most original.

Neo4j becomes very interesting when the relationships carry the value of the software. That covers complex permissions like those of a client portal or extranet, multi-level organisations, asset mapping and technical dependencies. It also covers recommendation engines, workflows, networks of stakeholders, traceability, business knowledge and any highly connected data.

In those cases a graph is not a technical whim. It is a more accurate way of representing the client's world. And when the model is accurate, the software becomes easier to explain, easier to evolve and often much sturdier.