A relational database describes entities and their attributes. A knowledge graph describes entities and their relationships. That distinction carries enormous implications for AI reasoning. When an AI agent queries a relational table, it retrieves a flat set of rows. When it queries a knowledge graph, it retrieves a network of connected facts: "Customer X bought Product Y, which is manufactured by Supplier Z, which is headquartered in Region W, which is currently under a trade embargo." A Data Knowledge Graph for AI is this relationship network, built specifically to enrich the context available to autonomous analytical agents.
Nodes, Edges, and Properties
Knowledge graphs model the world using three constructs. Nodes represent entities (a customer, a product, a supplier, a region). Edges represent typed relationships between nodes ("customer PURCHASED product," "supplier LOCATED_IN region"). Properties are attributes attached to nodes or edges (the purchase date, the quantity ordered, the current trade status). Together, these three constructs capture the structural knowledge that flat relational tables cannot represent without complex multi-table joins.
GraphRAG: Combining Graphs with Retrieval
The most productive use of knowledge graphs in AI systems is through a pattern called GraphRAG (Graph Retrieval-Augmented Generation). When an AI agent receives a query, it first traverses the knowledge graph to collect a network of relevant entities and their relationships. This graph-based retrieval is richer than standard vector similarity search because it returns structured, logically consistent facts rather than semantically similar text fragments.
A typical GraphRAG query might ask the graph: "Starting from Customer X, traverse all purchase edges in the last 90 days, then retrieve the supplier nodes for each purchased product, and flag any supplier currently marked as high-risk." The resulting subgraph is serialized and injected into the LLM's context alongside the user's natural language question. The LLM then reasons over a factually grounded set of relationships rather than relying on the probabilistic pattern-matching it would use without that context.
Storing Graphs in the Lakehouse
Knowledge graphs do not require a dedicated graph database for all use cases. When the entity count is in the millions rather than billions, the graph can be stored as two Apache Iceberg tables: a nodes table and an edges table. The nodes table contains entity IDs and their property attributes. The edges table contains source node ID, target node ID, relationship type, and edge properties. An AI agent can traverse this graph using recursive SQL queries (using Common Table Expressions with WITH RECURSIVE) directly through Dremio, without introducing a separate graph database technology into the stack.
Keeping the Graph Current
A stale knowledge graph is worse than no graph at all. If a supplier is flagged as high-risk but that edge is not updated in the graph, the AI agent will give the user a dangerously incorrect risk assessment. Knowledge graphs in the Agentic Lakehouse should be treated as streaming data products. Change Data Capture (CDC) pipelines from operational systems write new edges and update node properties in near real-time as business events occur, ensuring the graph reflects the current state of the enterprise.
