How AMD Built a Zero-Copy GraphRAG Layer on Iceberg with PuppyGraph

Summary

AMD built its Data Intelligence Platform on an open architecture centered on Apache Iceberg. However, grounding chatbot and agent answers in enterprise context required reconstructing relationships distributed across its Iceberg tables. As relationship paths grew longer and spanned more tables, it became increasingly difficult for LLMs to infer the required joins and generate grounded answers. AMD therefore used PuppyGraph to add a zero-copy knowledge graph layer over the existing Iceberg data, enabling multi-hop queries and supplying connected context for GraphRAG without loading and continuously synchronizing a separate graph store.

The Challenge: From Centralized Data to Connected Context

AMD set out to build a Data Intelligence Platform: a way to make enterprise data available as governed context for analytics and for AI applications such as chatbots and agents. As the data foundation for that platform, AMD consolidated enterprise data that had previously been distributed across many systems onto an open architecture built around Apache Iceberg. An earlier idea, leaving the data where it was and building an index layer over it, had not held up, because the relationships between those sources mattered as much as the records themselves. As Rajdeep Sengupta, Director, Systems Engineering at AMD, put it: “A lot of people promised us that you don’t have to bring your data, the data can sit anywhere, we will build you an index and it will work. It doesn’t work. We have seen it in practice.”

Consolidation solved the problem of where the data lived, but not the problem of how it was connected. Context about how users, devices, applications, servers, and other enterprise entities were related was distributed across records and attributes in many different tables. Reconstructing this context required joins, and as the relationships relevant to a question spanned more tables, the join chains grew complex enough that an LLM could no longer reliably infer them and generate a query that returned a grounded answer. Joins across two or three tables were manageable, but, as Sengupta put it, “what if the join needs ten different tables?”

A knowledge graph makes relationships explicit and traversable across multiple hops, supplying connected context for GraphRAG (retrieval-augmented generation over a knowledge graph). But AMD’s Iceberg data was large and continuously updated by upstream batch and streaming pipelines, and loading it into a separate graph store would have added another data-loading and synchronization path to build and maintain. AMD needed those relationships available as current, governed context for GraphRAG, without a separate graph-data copy to create and keep in sync.

“The graph is important because the data is continuously changing. We have to choose a graph which is highly scalable, because we are talking about petabytes of data. It is not a few terabytes of data. It has to be a scalable graph. We cannot afford to do a loading of data, because loading of data will be another ETL challenge. So we don’t have to do loading of data. Why can’t the graph just point to our Iceberg data and just learn itself?”

‍

Rajdeep Sengupta, Director, Systems Engineering, AMD

The Solution: A Zero-Copy GraphRAG Layer with PuppyGraph

AMD built its Data Intelligence Platform around an open data architecture, with Apache Iceberg as the table format at its foundation. PuppyGraph fit directly into this design as a graph query engine over the existing Iceberg tables. AMD could add a graph layer without creating a separately managed copy of the data and without replacing its storage, ingestion pipelines, catalog, or SQL engine.

The architecture reads from top to bottom. Existing batch and streaming ingestion paths, including Kafka-based streaming workloads, continued to bring AMD’s enterprise data into the platform. The data remained where it already was: in Parquet files managed as Iceberg tables on MinIO object storage, with Nessie providing the Iceberg catalog. Spark and Dremio operated over that foundation for processing, SQL, and Iceberg table operations. PuppyGraph sat alongside them as a graph query engine over the same Iceberg tables: an additional way to query the data, not a replacement for any existing component. Security and access context from the underlying data layer could flow through PuppyGraph to the applications and agents downstream.

Several properties of PuppyGraph made it a natural match for AMD’s requirements:

• Zero-copy graph access. PuppyGraph mapped Iceberg tables and columns to the vertices, edges, and properties of a graph model, then executed graph queries against the underlying data directly. There was no step that loaded the data into a separately stored graph.
• Multi-hop relationship queries. PuppyGraph provided a graph query layer, including Cypher, for traversing relationships across many hops, the same paths that would otherwise require increasingly complex joins for an LLM to construct.
• No separate graph synchronization pipeline. Because PuppyGraph operated over AMD’s Iceberg foundation, AMD did not need to build and monitor a separate pipeline for continuously loading data into a persisted graph store.
• Query performance options. PuppyGraph’s adaptive and full-cache execution modes gave AMD options for balancing response-time requirements against available compute and memory, depending on the workload.
• Schema evolution. Iceberg tables change, and the graph layer could accommodate changes in the underlying schema when the corresponding metadata was available.
• Scale. The architecture supported Kubernetes deployment, scaling through leader and execution nodes as query workloads demanded.
• Security and access. Security and access context from the underlying data layer could be carried into PuppyGraph and preserved for downstream chatbots and agents, so graph-grounded answers respected the same controls as the data platform itself.

In this case, zero-copy means avoiding a separately copied and continuously loaded graph store. AMD’s upstream ingestion and processing pipelines remained part of the architecture.

On top of this layer, connected context became something applications could simply query. PuppyGraph exposed the graph through query interfaces, including Cypher for multi-hop traversals, and chatbots and agents could reach that context either directly through graph APIs or through an MCP layer. AMD used this architecture to support a permission-aware chatbot grounded in graph context. Its downstream design also included an agent-and-critic pattern: one model generated the graph query, while another checked the interpretation and answer before it was returned.

For security investigations, the same connected context could link a user to their device, physical location, network, VPN session, and endpoint security activity. This broader context could help analysts assess whether a flagged alert might be a false positive.

The Result and What’s Next

The result is architectural. AMD extended its existing Iceberg foundation from SQL access to both SQL and graph queries without introducing a separately loaded and continuously synchronized graph store. PuppyGraph made relationship context available to chatbots and agents while preserving the security and access context of the underlying data platform. And AMD retained its open storage, catalog, ingestion, processing, and SQL architecture rather than building and operating a parallel graph-data stack.

The same pattern points at AMD’s next direction: multimodal GraphRAG. Enterprise context does not live only in tables. It also exists in documents, images, audio, and video. In the approach AMD is developing, a vector database manages the embeddings and semantic retrieval for that multimodal content, while properties and references extracted from it are represented in the graph and connected to existing enterprise entities. Vector retrieval identifies semantically relevant content; graph traversal supplies the relationships and enterprise context around it. Together they can route an AI application to the right context across both modalities. The extension keeps the same discipline as the graph layer itself: no duplicate graph-data store. The original content and its embeddings remain in the vector system suited to manage them, while the graph carries the connected metadata and references.

With PuppyGraph, AMD could keep data in the systems best suited to manage it while using a graph layer to connect and deliver its context to AI applications.

Further resources

• Graph RAG with Iceberg — San Francisco Apache Iceberg Meetup, October 2025
• Graph RAG with Iceberg — Bangalore Apache Iceberg Meetup, November 2025
• GraphRAG: Empowering the Next Generation of Autonomous Agents — New York City Apache Iceberg Meetup, January 2026