Zero copy GraphRAG helps enterprise teams expose the relationships between people, devices, applications, transactions and operational events without creating another data repository. For AI assistants, chatbots and agents, these connections can make the difference between a generic answer and one that is accurate, relevant and permission-aware.
This approach lets organisations query connected context directly from an existing data lakehouse foundation. Instead of loading and synchronising data into a separate graph store, a graph query layer can make relationships across governed data available for analytics and enterprise AI.
Business Value at a Glance
Connected Context
Multi-hop relationship queries reveal business context that isolated tables cannot easily provide.
Reduced Data Duplication
Rather than maintaining a separate, continuously synchronised graph-data store, teams can query a graph layer over existing data.
Governed AI Answers
Permission-aware context helps chatbots and agents respect underlying data access controls.
Scalable Investigation
Graph traversal supports faster exploration of complex relationships across large enterprise datasets.
From Centralised Data to Connected Context
Modern enterprises collect valuable data across finance, operations, customer channels, technology platforms and security tools. Bringing this data into a common architecture, such as Apache Iceberg tables on object storage, is therefore an important first step towards better analytics and AI readiness.
However, centralisation alone does not automatically create usable context. Relationships between records may span many tables: an employee may link to a device, the device to a network session, the session to an application, and the application to a support ticket or security event. Although a conventional SQL query can join these records, complexity rises quickly when a question requires several relationship steps.
This creates practical operational challenges:
- Data professionals spend significant effort understanding table structures and constructing complex joins.
- AI models may struggle to identify the correct sequence of joins across a large, evolving enterprise schema.
- Consequently, chatbot answers may lack important context, reducing trust and increasing the need for human review.
- Creating a separate graph database can introduce another extract, transform and load process, as well as ongoing reconciliation work.
- Data that changes through batch and streaming processes can become inconsistent when graph copies do not update reliably.
- Furthermore, security and access controls can become harder to maintain when teams replicate information into additional platforms.
The AMD GraphRAG case study from PuppyGraph illustrates this challenge. AMD had consolidated enterprise information around Apache Iceberg but needed a practical way to expose connected context for AI applications. As relationship paths expanded across more tables, relying on an LLM to infer increasingly complex joins became unreliable.
For Malaysian enterprises, the same issue can appear in many environments. For example, a bank may need to connect customer interactions, account activities, applications and service cases. Similarly, a government agency may need to trace relationships between citizens, cases, documents, payments and approval workflows. A GLC may also need to investigate how assets, vendors, projects and operational events affect one another.
Zero copy GraphRAG Architecture
Zero copy GraphRAG combines graph-based relationship retrieval with generative AI while retaining the lakehouse as the central data foundation. Instead of providing an AI model with only individual documents or rows, this pattern can supply connected entities and their relationships as supporting context.
In the AMD architecture described by PuppyGraph, Apache Iceberg remained the foundation for structured enterprise data. The platform stored data as Parquet files managed through Iceberg tables on MinIO object storage, while Nessie served as the Iceberg catalog. Meanwhile, Spark and Dremio continued to support processing, SQL access and table operations.
PuppyGraph added a graph query engine over the same Iceberg tables. This approach did not replace existing storage, ingestion, catalog or SQL components. Instead, it gave users and applications another way to query the data through graph relationships.
Mapping Tables to a Graph
A graph model represents information as:
- Vertices, representing entities such as customers, employees, devices, suppliers or applications.
- Edges, representing relationships such as owns, uses, reports to, accessed, approved or connected to.
- Properties, representing attributes such as dates, status, location, risk classification or transaction values.
A graph query layer maps existing tables and columns into this model. The underlying source data remains in the Iceberg environment; however, users and applications gain the ability to traverse relationships through graph queries, including Cypher.
In this context, “zero-copy” means avoiding a separately stored graph copy that requires continuous loading and synchronisation. Nevertheless, organisations still need well-managed upstream ingestion, data preparation and governance processes.
Enabling Multi-Hop Queries
Multi-hop graph queries are particularly useful when a business question involves several linked entities. For example, an IT or security analyst may need to investigate a suspicious event by connecting:
- A user associated with the alert.
- A device used by that individual.
- The user’s physical location or department.
- Relevant network or VPN activity.
- Endpoint security events and application access records.
Building this path repeatedly through SQL can require extensive joins and schema knowledge. By contrast, a graph query makes the connection pattern explicit and helps users and AI applications retrieve a broader view of the situation.
In the AMD use case, this connected context supported a permission-aware chatbot. The downstream design included an agent-and-critic approach: one model generated a graph query, while another checked the interpretation and response before the application returned it.
Keeping Data Controls Intact
Enterprise AI should not bypass established access policies. The source case shows how the underlying data layer can carry security and access context through the graph layer to downstream applications and agents.
For organisations handling sensitive financial, customer, employee or operational data, this principle is essential. A chatbot should retrieve only context that its authorised user can access. Therefore, teams should design for access control from the start rather than add it after an AI proof of concept expands.
Supporting Evolving Data Platforms
Iceberg-based environments support large, changing datasets. In the source architecture, batch and Kafka-based streaming workloads continued feeding the data platform while the graph layer operated over the shared foundation.
Accordingly, teams should plan a graph layer alongside schema evolution, metadata management, data quality checks and workload performance needs. PuppyGraph offers adaptive and full-cache execution modes, giving organisations options to balance response time with available compute and memory resources. It can also scale through Kubernetes-based deployment patterns as graph query demand grows.
Zero copy GraphRAG for Enterprise AI Applications
A Zero copy GraphRAG pattern is relevant where relationships matter as much as individual records. Consequently, organisations can apply it to several enterprise use cases:
Security and Technology Operations
Security teams can explore how identities, devices, applications, network sessions and endpoint events connect. As a result, they can triage incidents with more context, identify related activity and assess whether an alert may be a false positive.
Customer and Service Intelligence
Financial institutions, insurers and takaful operators can connect customer profiles, service interactions, products, claims, cases and communications. AI-enabled service teams can then use governed context to understand the wider history surrounding a customer request without relying on fragmented searches.
Operational and Asset Management
Large enterprises and GLCs can connect equipment, work orders, suppliers, locations, projects and maintenance histories. Relationship-driven analysis may therefore help operations teams understand dependencies and identify the downstream implications of an issue.
Compliance and Case Management
Government agencies and regulated organisations can use connected data to trace cases, approvals, supporting documents, payments and responsible parties. In turn, graph relationships can improve investigation workflows while maintaining appropriate access boundaries.
Zero copy GraphRAG and Multimodal Content
Structured tables are only one part of enterprise knowledge. Important context may also exist in policies, emails, reports, images, call recordings, videos and technical documentation.
The AMD case study points towards a multimodal Zero copy GraphRAG direction. In this model, a vector database manages embeddings and semantic retrieval for unstructured content, while a graph represents extracted properties, references and relationships connected to enterprise entities.
The two retrieval methods address different needs:
- Vector retrieval finds content that is semantically relevant to a question.
- Graph traversal identifies how that content relates to customers, systems, processes, people or events.
- Consequently, an AI application can use both methods to assemble better-grounded context before generating a response.
This design avoids forcing all information into one technology. Instead, original content and embeddings remain in systems suited to managing them, while the graph provides relationship metadata and navigational context.
How ORTECH Helps
ORTECH helps organisations move from disconnected data and AI experimentation towards practical, governed analytics engineering solutions. For a GraphRAG use case, this starts with understanding the business questions that teams need to answer, the data sources involved and the access controls that they must preserve.
Our approach can include requirements assessment, data landscape review and solution design for AI-ready data platforms. In addition, ORTECH can help identify high-value relationship paths across existing tables, define a practical graph model and establish data quality rules that improve the reliability of connected context.
We can support data integration and analytics engineering work to prepare, validate and document source data before analytics or AI applications use it. This includes designing repeatable workflows for data preparation, exception handling, reconciliation and metadata management.
For organisations using analytics automation platforms such as Alteryx or Alteryx One, ORTECH can help build governed workflows that prepare and validate information before it enters the lakehouse or becomes available to downstream AI processes. These workflows can reduce manual data handling, improve repeatability and provide clearer auditability for data transformation steps.
ORTECH also supports governance, user enablement and adoption. Technology alone does not create trusted AI outcomes; instead, business owners, data teams, IT teams and risk stakeholders need shared definitions, clear operating processes and the skills to use connected data responsibly. For further guidance, see our Enterprise AI Readiness Checklist for Leaders.
Zero copy GraphRAG Outcomes and KPIs
The AMD example is an architectural case study and does not provide quantified performance or financial outcomes. Therefore, organisations considering a similar approach should define their own baseline measures and evaluate improvements through a controlled implementation.
Potential outcomes include faster access to connected context, lower effort spent managing duplicate graph data, improved investigation quality and stronger governance for AI-enabled decision support.
Relevant KPIs may include:
- Time required to investigate a multi-system operational or security issue.
- Number of manual queries or handoffs needed to answer a relationship-based question.
- Query turnaround time for approved graph-based use cases.
- Data freshness between source tables and AI-accessible context.
- Number of data reconciliation exceptions caused by duplicated data stores.
- Percentage of AI responses requiring human correction or escalation.
- Exception resolution time for customer, operational or security cases.
- Audit traceability of data sources, transformations, access controls and generated responses.
A successful pilot should focus on a limited set of high-value questions rather than attempting to model every enterprise relationship immediately. This approach enables teams to validate data quality, query performance, access controls and user adoption before expanding the graph model.
Building a Practical Roadmap
A Zero copy GraphRAG roadmap starts with business priorities. First, identify questions that currently require extensive manual investigation, complex SQL joins or repeated searches across systems. These questions are strong candidates for graph-based context because they depend on understanding relationships, not simply retrieving individual records.
Next, assess the readiness of the underlying data platform. Source data should have clear ownership, consistent identifiers, reliable metadata and appropriate access controls. Teams should address data integration and quality issues early because a graph layer makes existing relationships easier to explore but cannot correct inaccurate source records on its own.
Organisations can then develop a focused graph model, test representative multi-hop queries and evaluate GraphRAG with business users. Where chatbots or agents are involved, controls should include permission-aware retrieval, response validation, monitoring and human escalation routes for sensitive or high-impact decisions.
By retaining the established lakehouse as the central data foundation, organisations can add relationship intelligence without automatically creating another large-scale data replication and synchronisation burden.
Talk to ORTECH
Planning an AI-ready data platform or exploring how GraphRAG can improve connected enterprise context? ORTECH can help assess your data architecture, design governed integration workflows and define practical use cases for relationship-driven analytics and AI.
