Knowledge Graph in the company: Your data warehouse understands nothing

As of: July 2026.

1. The order question: an example from e-commerce

Let's start with the day-to-day business of an online retailer. An order has been received, five items, the customer is expecting a delivery date. The shipping department now comes up with a question that is answered hundreds of times a day:

«How do we ship this order? How many parcels will there be, from which logistics location, with which logistics provider?"

An experienced dispatcher will answer you in seconds. He knows that position three is only in stock at the East location and the rest comes from the central warehouse. He knows that this will result in two packages and that only one logistician can handle the heavy one. He didn't calculate the answer. He derived them based on relationships that he has in mind: item to inventory, inventory to location, location to logistics provider, logistics provider to tariff and delivery time.

Your database has the same ingredients, whether it is operated as a data warehouse, SAP BW or lakehouse. Orders, positions, items, stocks, locations, tariffs, logisticians: everything is neatly stored, historicized, and queryable. And yet it doesn't provide the answer in seconds, but in one project. The answer is not in a table. It lies between the tables.

A knowledge graph in the company closes exactly this gap, and that's where this article begins. If you plan an enterprise AI that is supposed to answer relationship questions, you decide on a data structure, not just a model. The ordering question accompanies us throughout the entire text. Every architecture that appears here must be measured against it.

2. What a knowledge graph is and what it is not

You know the picture from every crime story: the bulletin board in the detective's office. In the middle is the photo of the victim, around it are suspects, places, times, and in between the common threads: knew, was seen with, has an alibi from. No investigator solves the case with a list of all the people involved. He loosens it using the threads. Exactly this principle, applied to business data, has a name: A knowledge graph is the structured representation of a business area as a network of nodes, edges and properties.

The three building blocks correspond to the pinboard. Nodes are the photos and maps, i.e. in the store an order, an item, a logistics location, a logistics provider. Edges are the threads, directed and typed. An edge doesn't just say that the item and the location have something to do with each other. It says "is in stock" with direction and meaning. Characteristics are the notes on the card and thread: the inventory at the warehouse edge, the maximum weight at the logistician.

In the graph, relationships are full-fledged data objects with direction, type and their own properties. Technical language calls them first-class citizens, equal to the data itself. In the relational world, relationships are by-products of foreign keys that only a query brings to life. In the graph, the meaning is in the structure of the network. Google shows that this principle works on a large scale: As early as May 2020, the company estimated its Knowledge Graph at over 500 billion facts on around 5 billion entities. The info panels next to the search results are traversals of this network, i.e. traced edges, not full-text hits.

The trade-off: Today, the first draft of a graph can be automated, but the responsibility for it cannot. Tools like the Genie Ontology learn business context from metadata and usage, and language models extract entities and relationships from documents. What emerges is a suggestion: observed connections. Whether an edge is considered a business rule, which tariff is binding, who approves a change, that remains a decision in-house. Two reasons speak against the blind adoption of automatic graphs: Anyone who works under comprehensibility requirements must be able to defend the derivation of an answer, and a graph that no one in the house understands cannot do this (Chapter 6). And the real value of the graph is that it represents your knowledge, not just your data patterns.

3. Why tables fail when it comes to relationship issues

Back to the order question. As a model calculation: In a typical e-commerce data model, the order question touches nine to eleven tables and chains eight to twelve joins. Order, order position, item, inventory, logistics location, zone assignment, tariff, logistics provider, service type, plus, depending on the model, shipment and package. The actual logic is still not in the query. Inventory splitting, package formation based on weight and volume, logistics selection based on zone and transit time move into application code or a procedure outside the platform. Each additional corner of the question multiplies the intermediate results. Document databases only postpone the problem: relationships there are second-class references, and the application glues the parts together using lookups.

A native graph engine physically stores relationships with the data: tracing an edge costs one step, not a table scan. The literature calls this principle Index Free Adjacency. The answer to the ordering question is then a path over four relationship types instead of a join mountain range. The path: Order contains position, position is in stock in location, location is served by logistician, logistician offers service type with tariff. The cost of traversal grows with the length of the path, not with the size of the entire inventory.

For anyone who wants to do the math: the calculation behind the difference. As a model calculation, take a shop with 50,000 orders per year, an average of three items per order, each item stocked at two to four locations. The SQL variant of the order question first combines positions against stocks and thus creates six to twelve intermediate lines per order. Zones, service types and tariffs are then added, with several entries per logistics provider. Before the actual selection logic, there are quickly 50 to 150 intermediate lines for a single order, and the optimizer has to plan each stage across the entire inventory. The traversal, on the other hand, starts at the node of one order and only touches its own edges, in the order of 15 to 40. Everything about it is bandwidth and model, not a measurement. But the direction of the difference is structural, and it grows with each further corner of the question.

The trade-off: For aggregations over millions of rows, the Lakehouse with SQL remains the right tool, by a wide margin. The Lakehouse, Databricks' combination of data warehouse and data lake on one platform, shows its strengths there: sales per month, inventory range per assortment, cohort analyses, all table work. The graph wins for questions about multiple vertices with few starting points. Anyone who declares one of the two tools to be a universal tool is repeating the tool religion with a new sign.

4. The context layer: where the knowledge graph sits in the company

“AI has a context problem, not an intelligence problem.” The sentence comes from the Databricks CEO from the keynote at DAIS 2026, the Data + AI Summit. The same conference spoke of over 100,000 agents built and that the actual agent loop accounts for around 1 percent of the effort, versus 99 percent of context and infrastructure work. The diagnosis corresponds to the model that I introduced as a context layer. The context layer has four layers: The glossary defines the terms, the semantic layer defines the key figures, the ontology defines the relationships, the agent context defines the rights and views of the agent. The knowledge graph is the third layer in executable form.

Databricks visibly builds these layers into the platform. At DAIS 2026, Unity Catalog announced a glossary for binding business terms (preview announced, as of June 2026). Metrics define key figures centrally as reusable objects (partly public preview). Domains tailor data areas so that agents see limited, relevant context instead of the entire catalog (public preview). The Genie Ontology continuously learns business context from this semantic foundation. Layers one, two and four take shape directly in the catalog.

Table 1: The four layers of the context layer and their Databricks equivalent. What becomes visible is that the platform delivers three layers, the third remains modeling work in-house.

The third layer is the most demanding: Tools can suggest the technical topology, your department must be responsible for it. Lineage and table statistics describe how data is technically related. However, the ordering question requires business knowledge: which location serves which logistics provider, which tariff applies from which weight. Anyone planning the context layer therefore sizes the third layer based on questions such as the order question and not based on the feature catalog. My [white paper on the context layer](https://beyond-chaotic-analytics.ch/docs/Whitepaper_Context Layer_v3.0.pdf) describes step by step how the four layers are created in-house, from the term inventory to the agent context. You can also find an introduction to the same model in the article Making data AI-ready.

5. How the graph gets into the lakehouse: Connector, Unity Catalog, GraphRAG

A graph next to the Lakehouse sounds like a second island, and that's exactly the silos we wanted to end. The concern is justified, the answer is reassuring. The connection between Graph and Lakehouse has been standard since 2024. Since June 2024 there has been an official connector between Databricks and Neo4j, tested by both manufacturers. It moves data in both directions: from delta tables to the graph and back. The graph is fed from the same verified sources as every report in the company. Who accesses what and where a number comes from remains visible in Unity Catalog.

The question remains how the AI ​​uses the graph. Databricks published a calculated example for this in May 2025, a so-called GraphRAG agent. Behind the technical term there is a three-step process. First: A language model translates the question, such as our ordering question about packages, location and logistics provider, into a query to the graph. Second, the graph answers the query by following the modeled relationships, from order to inventory to locations to rates. Third: The language model uses the result to formulate an answer in complete sentences, including the route to get there. This is not a similarity search with good marketing. It is a derivation along the lines of business relationships. What is remarkable about the example: The source was SAP ERP data, i.e. the type of relationship from which our order question also comes.

For more information: the announcement of the Neo4j Databricks connector (June 2024), the GraphRAG reference implementation on the Mosaic AI Agent Framework (May 2025) and the Unity Catalog innovations of DAIS 2026. The technical details are there: language model used, generation of Cypher queries, provision via model serving.

For everyone who will do it: what everyday life also demands. Three things are not announced and still determine success. Firstly, the loading frequency: the graph is fed from delta tables, as a nightly batch or as a stream, depending on the use case; Anyone who traverses stocks needs the stream, otherwise the agent justifies it with yesterday's stock level. Secondly, the mirroring of rights: access rules from Unity Catalog do not automatically apply in the graph; they must be adjusted for each node type and relationship type. Third, evaluation: The Databricks reference evaluates its agent responses via human feedback and model-driven metrics. This loop is not an addition for later, it is the only way to know whether the queries generated are using the model correctly.

The trade-off: The reference implementation is a demo scale, not an operational concept. GraphRAG costs noticeably more setup and ongoing maintenance than Vector RAG; the Databricks publication cited mentions this itself. Anyone who runs Neo4j alongside Unity Catalog also runs two governance rooms and has to actively keep them in sync. Feasible, but operational work, not a footnote.

6. The Audit Trail: Explainability as a Business Requirement

In regulated companies, AI projects rarely fail due to the quality of the answers. They fail because of a single query: “How do you know that?” A neural network produces results without proof. A vector retrieval provides something similar without derivation. What I have stated elsewhere applies to both: similarity is not checking, and frequency is not correctness.

The graph changes the evidence because the answer is a path. “Two packages, from the central warehouse and the East location, with logistics provider A and B” comes with the reason: Position three is only in stock at the East location. The weight of the remaining items exceeds the limit of the selected service type. The tariff for Zone 2 applies from the East location. Each of these statements is an edge that a subject matter expert can review, correct, or approve. Anyone who works under traceability requirements, for example according to BCBS 239 with its requirements for the origin and accuracy of risk data, will recognize the difference between an answer and a document. The black box becomes an audit trail. This also makes it possible to answer the question before signing: Will the same question lead to the same number next week, and who in the room can explain the derivation?

The trade-off: An audit trail is only as robust as the model behind it. An outdated edge, such as a tariff that no longer applies since January, produces an incorrect answer with perfect justification. Explainability is not a substitute for care. At least it makes care errors detectable.

7. When you don't need a graph

The strongest counterargument deserves full exposure. For the majority of today's enterprise AI use cases, Vector RAG is sufficient. If you want to make contracts, manuals and tickets searchable, you need embeddings, i.e. number vectors that represent meaning, and a clean decomposition of the documents. If you want to query key figures, you need metric views with clear definitions. Both are quicker to build, cheaper to operate and already at home in Unity Catalog. If that were the whole picture, this text would be a finger exercise.

The criterion on which the opposing position fails is the ordering question itself. As soon as a question crosses two or more corners and its answer is subject to a requirement for proof, it belongs on the graph. Obligation to provide evidence means: The answer triggers something operationally or has to withstand an examiner. In this case, similarity search structurally returns the wrong currency. She finds what sounds like the answer, and no one can show that it follows the rules of business. Count how many questions like this are in your own backlog. In my experience, it's less than half of the use cases, but almost always the highest stakes ones.

Table 2: Tool selection by question type. The criterion is the question, not a technology preference.

Two limits also belong in the protocol. First, the standard question about RDF, the W3C's Resource Description Framework. The standard formally describes knowledge cleanly; The labeled property graph model has become popular in operational AI pipelines because it is closer to application code and real-time operations. Anyone who needs to exchange knowledge between organizations in a standardized manner still checks RDF. Secondly, the question of care. A graph without ownership expires like any glossary. Without a named person responsible for each relationship type, the third layer in a year is a museum.

8. Balance sheet and audit questions for your own house

The silos that the subtitle promises to end will not disappear with more storage or with the next model. They disappear where relationships have the same status as values: modeled, centrally controlled, queryable. This is exactly what a knowledge graph does in the company. The database remains the foundation. Unity Catalog visibly becomes the home of layers one, two and four. The third layer, ontology, remains a decision that no platform makes for you.

Three test questions, posed to your own house: Which three relationship-related questions are taking up the most time for you today, and how many corners do they cover? Who could test the derivation of an AI answer to these questions tomorrow, and to what end? And who continues to maintain the relationship types when the project team is gone?

If your dispatcher answers the order question faster than your platform, that is not a compliment to the dispatcher.

If you want to check which relationship questions in your house belong on the graph first: Clarity Audit.

Glossary

BCBS 239: Basel Committee on Banking Supervision Principles for Risk Data Aggregation; require, among other things, verifiable origin and accuracy.

Cypher: Query language for property graphs, at home in Neo4j. Formulates paths instead of joins.

DAIS: Data + AI Summit, Databricks' annual conference.

Delta table: Lakehouse storage format at Databricks, transaction-safe on object storage.

Embedding: Number vector that represents the meaning of a text. Basis of similarity search.

Genie / Genie Ontology: Databricks feature that answers natural language questions against data; The Genie Ontology continuously learns business context.

GraphRAG: Retrieval Augmented Generation against a graph instead of a search index. The AI ​​fetches facts about modeled relationships.

Index Free Adjacency: Storage principle of native graph engines. Neighboring nodes are directly linked; tracking an edge does not require an index lookup.

Context Layer: Model coined in this blog of the four layers between raw data and reliable AI response: Glossary, Semantic Layer, Ontology, Agent Context.

Lakehouse: Databricks' architectural term for bringing together data warehouse and data lake on one platform. Takes on the roles that SAP BW and a separate data lake otherwise play separately.

LPG: Labeled Property Graph, the graph model of operational practice (including Neo4j).

Metric View: Metric definition as a centrally maintained, reusable object in Unity Catalog.

Mosaic AI Agent Framework: Databricks framework for building, evaluating, and deploying AI agents.

RDF: Resource Description Framework, the W3C standard for formal knowledge representation.

Traversal: Tracing edges through a graph, step by step.

Unity Catalog: Databricks' core governance layer for data and AI assets: access, lineage, semantics.

Vector RAG: Retrieval augmented generation via similarity search in embeddings.

Revision note: First version July 2026. Product statuses and preview information according to DAIS 2026.