SAP Knowledge Graph: When Relationships Become Data

An Ontology for the Autonomous Enterprise

Nodes represent real-world business objects such as customers, locations, orders, or invoices, while edges describe the explicit relationships between these entities (e.g., Customer A initiates Order B). The formal model of knowledge representation (properties)—known as the ontology—is built upon this structure. It defines standardized terms, hierarchies, and rules for the entire company.

Technically, this knowledge is usually represented using the Resource Description Framework (RDF) in the form of triples that follow a clear grammatical structure consisting of a subject, a predicate, and an object (e.g., Supplier X supplies Product Y). Unlike a simple SQL table, such a knowledge graph can be interpreted logically by both humans and machines.

SAP HANA Cloud Vector Engine

In this context, distinguishing this from vector databases (such as the SAP Hana Cloud Vector Engine) is of fundamental importance. A vector database transforms unstructured data into multidimensional numerical vectors (embeddings). This can result in spaces with hundreds of dimensions—a breeze for a computer, but unimaginable for humans: We usually stop at four dimensions—three spatial dimensions and the fourth dimension representing time.

Relationships between data points are calculated purely mathematically in multidimensional spaces using spatial distances (such as cosine similarity or Euclidean distances). This is ideally suited for similarity search in unstructured text (Retrieval-Augmented Generation, RAG), but remains a mathematical black box for the user, since the calculated relationships arise implicitly and cannot be explained logically.

A knowledge graph, on the other hand, defines relationships explicitly, transparently, and based on rules. While vectors represent the mathematical associations of AI, the knowledge graph embodies its logical and explainable set of rules.

Native Graph Integration in SAP HANA Cloud

For a long time, the practical use of graph databases in the SAP world was characterized by a painful data disjoint. Anyone who wanted to analyze complex relationship networks had to laboriously extract the data from the ERP system and transfer it to specialized third-party systems such as Neo4j. With the strategic HANA update in the first quarter of 2025, SAP closed this functional gap. Since then, the in-memory database HANA Cloud has offered native support for storing and searching knowledge graphs.

The database uses the established RDF syntax and the SPARQL query language. The greatest architectural advantage of this „multi-model“ approach lies in its direct combinability: Developers can seamlessly link relational SQL data with graph data in a single query or connect them via joins without having to replicate data.

SAP Knowledge Graph and SAP Virtual Data Models

The overarching SAP Knowledge Graph is built on this integrated database engine. It draws on the comprehensive metadata knowledge of the SAP Virtual Data Model (VDM) and creates an ontology that represents the inherent business relationships within S/4. This graph serves as a compass for the AI assistant Joule and autonomous agents. When a user asks Joule in natural language, „Show me overdue orders,“ the AI no longer has to guess the table structures. The knowledge graph navigates through the semantic web, identifies the correct whitelisted APIs, sets the appropriate filter parameters, and constructs a precise query. This drastically minimizes the risk of inaccurate or irrelevant results compared to pure LLM approaches.

As elegant as the concept sounds in theory, practical experience reveals the hurdles and risks this technology poses for existing SAP customers: A functional, enterprise-wide knowledge graph is not a turnkey product, but rather the result of a highly complex modeling process. The creation and ongoing maintenance of ontologies and graph structures require in-depth semantic expertise and tie up significant IT resources. Anyone who believes the software handles semantic structuring fully automatically is massively underestimating the complexity of individually tailored processes and custom tables that have evolved over time.

Data Quality, Capacity Units, and API Policy

A knowledge graph is no cure for poor data quality. If the underlying data foundation in the ERP system is incomplete, outdated, or inconsistent, even the most intelligent graph will only produce perfectly structured false statements. Complex graph analyses (such as path and loop searches) across highly interconnected, massive transactional datasets are computationally intensive. In-memory databases quickly reach their physical limits during such operations, which can drive up hardware costs for HANA Cloud instances relentlessly.

Technically, the Knowledge Graph is superbly designed, but commercially, it serves as a strategic toll booth for SAP. To fully leverage the benefits of graph technology, SAP is forcing its existing customers into the restrictive ecosystem of the Business Data Cloud (SAP BDC) and the Business Technology Platform (BTP or BAIP, Business AI Platform). Through usage-based billing models (Capacity Units) and restrictive API guidelines, SAP is attempting to maintain control over the business contexts of its existing customers and systematically block the unlicensed outflow of this valuable metadata to powerful, more affordable third-party AI platforms or hyperscalers.

Independent Alternatives Beyond the ERP Monopoly

However, existing SAP customers do not have to surrender to this monopolistic stranglehold without a fight. The market for database-specific AI queries and semantic layers is evolving rapidly and offers powerful, vendor-neutral alternatives:

Tools like vanna.AI offer flexible frameworks for connecting language model applications directly to existing SQL databases (from Snowflake to PostgreSQL to Oracle). By adding DDLs, documentation, and historical sample queries, the system learns the semantic relationships without the need to license an expensive SAP infrastructure.

The WrenAI framework impressively demonstrates how a semantic model can be built directly using a graphical editor, in which tables are defined as nodes and relationships as edges. WrenAI translates this knowledge graph into a standardized format that prevents redundant and ambiguous queries and generates precise SQL commands—without the need for the costly detour via the SAP BTP Generative AI Hub or Datasphere.

Specialized graph platforms such as Graphwise with GraphDB also demonstrate how enterprise-wide knowledge graph systems can be established based on open standards (RDF, OWL, SPARQL). These systems can orchestrate heterogeneous data sources and be directly linked to modern language models via intelligent plugins (such as the ChatGPT Retrieval Connector), while sensitive data sovereignty remains entirely within the organization’s control.

Personal Takeaways for the SAP Community

The Knowledge Graph is undoubtedly the technically superior paradigm for the future of enterprise AI, as it bridges the much-needed gap between the stochastic uncertainty of language models and the deterministic precision of business ERP systems. However, as a cautious existing SAP customer, you should decouple the adoption of this technology from SAP’s commercial platform doctrine. Leverage the multimodal capabilities of the HANA Cloud Graph Engine to cleanly structure your data. But consistently resist the temptation to lock your entire enterprise-wide semantic map exclusively into the expensive licensing trap of SAP BTP. The future belongs to open, interoperable data spaces in which the company retains absolute control over its business context and artificial intelligence.