Why Boldo Runs on Neo4j

A contrarian choice

Neo4j is mostly associated today with AI knowledge graphs, fraud detection, and cybersecurity analytics. These are the use cases the community highlights, the ones Neo4j itself puts forward in its messaging.

Boldo took a different direction. Two years ago, the team chose Neo4j as the primary operational database to build an Enterprise Architecture tool. Not as an analytics engine or a recommendation layer. As the product's core data store.

Two years of production later, the picture is mixed. Some assumptions proved right beyond expectations. Others required more work than anticipated. What follows is a factual retrospective, without promotion.

The original reasoning

Enterprise Architecture is fundamentally a story of connections. Applications depend on infrastructure. Processes rely on applications. Teams own processes. Everything is linked to everything, and that is precisely what most tools on the market model poorly.

In a relational database, these connections translate into junction tables. The richer the model, the more joins multiply. The more joins multiply, the more queries become complex and expensive. The starting hypothesis was that a graph database would model this reality more naturally. Nodes represent assets (applications, processes, teams, infrastructure) and the relationships between them carry their own context, without intermediaries.

What works

The metamodel lives in the graph itself

This is probably the most consequential architectural decision in the product. Boldo's metamodel, the structure defining what types of assets exist and how they can relate to each other, is itself a subgraph in Neo4j. It is a graph that describes a graph.

In practice, this means that each organization can shape its own model. Adding a new object type, creating a new relationship category, modifying the existing structure: all of this amounts to editing nodes and relationships in the database. There is no schema migration to plan, no service interruption, no update script to run.

For a startup that needs to iterate quickly on its data model, this flexibility was a real advantage. The early versions of Boldo's metamodel evolved several times a week during the first months of development. With a traditional relational schema, each change would have required a migration.

Relationships are first-class objects

In Enterprise Architecture, the link between two assets is often more valuable than the assets themselves. Knowing that a data flow exists between application A and application B is information. Knowing that this flow carries personal data, passes through a specific middleware, and was created as part of a given project is actionable information.

In a relational model, this type of context is spread across multiple tables. In a graph, the relationship itself carries these attributes natively. The query to find all flows carrying personal data between two business domains is direct. It does not traverse six junction tables.

What was harder than expected

Data integrity rests entirely on the application

Neo4j does not impose implicit schema constraints. When the metamodel itself is dynamic, the validation layer must be smart enough to follow its evolutions. Consistency rules are defined by the application, and the application is responsible for enforcing them.

The team underestimated the discipline this requires. In a relational database, the schema prevents certain inconsistencies by default. In Neo4j, nothing prevents the creation of an orphan node or a relationship between two object types that should not be connected. The application-side validation layer represented a significant development investment.

Not everything belongs in a graph

After several months of production, Boldo evolved toward a hybrid architecture. The graph remains the core of the operational model, managing assets, their relationships, and the metamodel. But certain data is stored elsewhere, in systems better suited to their nature.

Accepting that the graph is not the answer to every storage need was an important step. The initial temptation to centralize everything in Neo4j gave way to a more pragmatic approach, where each type of data is stored in the best-suited system.

The ecosystem is smaller

Compared to relational databases, the Neo4j ecosystem offers less online content, fewer battle-tested patterns for standard transactional applications, and fewer documented case studies for operational use cases.

In practice, this means that many problems are solved through experimentation rather than a quick search. Stack Overflow answers are fewer. Architecture patterns for SaaS products built on Neo4j are rare. The team learned by building, which takes more time than relying on documented solutions.

The verdict after two years

Neo4j was not a trendy choice. It was a structural one. When the product being built is fundamentally about how things connect, and when the very definition of "how things connect" needs to remain flexible, a graph that describes itself was the most coherent architecture available.

The choice delivered on its promises regarding metamodel flexibility and relationship richness. It required a larger investment than anticipated on data validation and on managing the cases where the graph was not the right tool.

The team would make this choice again. With a better anticipation of the complexity involved.