App Orchid vs. Neo4j: What a Graph Database Does and What a Context Layer Adds

The Short Answer

Neo4j is a graph database. It stores entities and the relationships between them, and it traverses those relationships quickly.

A context layer is the infrastructure between enterprise data and AI systems that encodes what the data means. It has three parts:

• Business semantics. Metric definitions.
• Business vocabulary. The informal terms people use when they ask questions.
• Ontology. A machine-readable map of entities and their relationships.

Neo4j is infrastructure for the third part. It defines how you store and query a graph. It leaves open:

• Where the graph content comes from
• How business metrics are defined and enforced
• How a user's phrasing maps to your schema
• How an agent's access is controlled and recorded

What Neo4j Does Well

Neo4j is a property graph database. What it gives you:

• Cypher, a mature query language for traversing relationships
• A graph algorithms library for paths, communities, and centrality
• Vector indexing for similarity search alongside traversal
• Aura, managed hosting
• Virtual Graph, which reads from cloud data sources without a full copy
• Aura Agent, for building agent applications against the graph

Neo4j reports that most of its new business now comes from customers using the graph as an AI knowledge layer. Retrieval that follows explicit relationships does ground a language model better than retrieval over unstructured text alone.

Choosing Neo4j settles the storage question. It does not tell you how much of a working context layer you already have, or how much your team still has to build.

Gap One: A Graph Does Not Store Metric Definitions

A graph can record that a Customer holds a Contract, and that the Contract belongs to a Region. It has no place to record that "active customer" excludes accounts in a 90-day grace period, that revenue is recognized on invoice date rather than order date, or that the finance team and the operations team define "site" differently.

Those definitions exist somewhere in your systems today - usually in BI tool logic, in SQL views, in dbt models, and in the knowledge of a few individuals. However, Cypher will not read them.

An agent querying the graph traverses relationships correctly, but can calculate values incorrectly. It finds every contract connected to a customer. It does not know whether to sum them the way your finance team does, and the graph will not tell it.

Gap Two: Users Do Not Use Schema Terms

Your graph is labeled in schema terms. Asset, WorkOrder, CostCenter. Your users ask about "the north plant", "the Riyadh job", "the old SAP numbers", "T3 outages". Nobody types node labels.

The graph database does not store the mapping between those two sets of terms. A text-to-Cypher or GraphRAG pipeline passes the model the graph schema: node labels, relationship types, and property names. When a term in the user's question does not appear in that schema, the model resolves it by approximate string or embedding similarity to the nearest label it was given. It then emits syntactically valid Cypher against that label.

This is the least discussed failure mode in GraphRAG deployments. The traversal executes correctly, the query returns rows, and the answer is still wrong, because the model selected the wrong entity before retrieval started. The result gives no indication that the model matched the term approximately.

Capturing that vocabulary is a data collection problem across documentation, data dictionaries, BI annotations, and direct user input. It is ongoing work, and it is not a database feature.

Gap Three: The Graph Is Authored Once, and Then It Becomes Out of Date

Neo4j's own guidance on building an enterprise knowledge layer is direct about this. The platform provides the foundation and the framework. Your organization supplies the knowledge that goes into it, and that work runs mostly bottom-up.

That means modeling entities, writing ingestion pipelines, resolving duplicate identities across source systems, and maintaining all of it as schemas change. Virtual Graph reduces the copy burden for some sources. It does not reduce the modeling effort, which is the larger cost.

Most teams end up with a graph that is accurate on the day it ships and out of date within a few quarters. The context kept changing, and nobody owns the re-modeling.

The Comparison

Read the middle column as "the graph database itself", not "Neo4j plus six months of your team's work".

The last row determines project cost. Your team can build every row above it. Your team then maintains all of it, indefinitely.

What You Build on Top of Neo4j to Reach a Context Layer

If you build rather than buy, this is the full scope for your team.

• Schema and data crawl. Read source schemas, sample distributions, infer candidate entities and relationships. Otherwise a person models each domain by hand.
• Metric extraction. Recover metric logic already stored in BI tools, SQL views, and dbt models, then reconcile the conflicting versions.
• Vocabulary capture. Collect informal terms, synonyms, and local naming from documents and users. Report the gaps rather than letting the model guess.
• Grounded query generation. Restrict the language model to the ontology and the metric definitions, not just the schema.
• Agent governance. Permissions that agents inherit from your identity provider and cannot bypass, plus a record of every question, query, and result.
• Maintenance. All of the above, again, whenever a source system changes.

App Orchid builds this as a product. It generates the ontology, metrics, and vocabulary from your existing systems, and your people review them rather than write them. Queries run against source systems rather than a duplicated graph. Agents reach the layer through context APIs and an MCP interface, so the platform enforces one permission model instead of one per application.

When Neo4j on Its Own Is The Correct Choice

Choose a graph database and skip the context layer when graph traversal is a requirement. E.g., fraud ring detection, supply chain dependency analysis, network topology, identity resolution as a product feature, recommendation traversal. In these cases you need graph algorithms operating on a purpose-built model, and a general business context layer adds nothing.

The same applies if you already have a well-modeled domain graph, a team that owns it, and no requirement to answer open-ended business questions in natural language.

When You Need a Context Layer

• Agents or analysts need to answer business questions that cross system boundaries, where the same entity is represented differently in each system.
• Every answer has to be auditable. An auditor, a regulator, or an executive will ask how you produced a number, and "the model retrieved it" does not answer the question.
• Users ask in their own terms rather than in schema terms, and those terms vary by region, function, and length of service.
• You cannot staff continuous ontology authorship. The model has to maintain itself against changing sources, with your team reviewing rather than writing.

They Are Not Mutually Exclusive

A graph database can sit underneath a context layer, and in some architectures it should. These are two different layers of a system, and choosing one does not rule out the other. Neo4j stores connected data and traverses it. A context layer is what agents call when they need to know what any of it means.

Frequently Asked Questions

Is App Orchid a graph database?

No. App Orchid uses an ontology and a knowledge graph internally, and queries source systems directly rather than requiring data to be loaded into a separate graph store.

Can App Orchid work alongside Neo4j?

Yes. Neo4j can be one of the connected sources, and graph-specific workloads can continue to run against it.

Does GraphRAG solve the context problem?

It improves grounding for retrieval. It does not supply metric definitions or map user terms to schema, so accuracy on business questions still depends on the layer above the graph.

What is the difference between an ontology and a context layer?

An ontology models entities and relationships. A context layer contains an ontology plus metric definitions and business vocabulary. Every context layer includes an ontology. Not every ontology is a context layer.