Earlier today, I had a chat with Prof. Dr. Jörg W. Fischer over his LinkedIn post saying – we are entering a decade of structures”. The message caught my attention and hit my brain with the question – what means structure?
PLM vendors like to speak about product structures. For example, Dassault Systemes and their 3DEXPERIENCE platform defines so called “unified product structure” that eliminates the need to synchronize BOMs.
However, Dr. FIscher is speaking that structures are everywhere and not in PLM, but also in ERP systems. Here is a passage: Have you ever wondered why we only talk about structures in PLM? The exciting thing is that ERP systems are also full of structures. It’s just much harder to see them there. If you don’t believe this, I recommend that you take a closer look at SAP S4/HANA. There is a multitude of structures there that far exceed the structures in PLM systems!
Let’s leave the naming debates between PLM and ERP vendors for some time. The most interesting part of the conversation was about what is a “structure” and how it can be modeled. Especially, I want to speak about why “graphs” are actually one of the best known ways today to manage a product structure such as a complex BOM.
History, BOMs, and Graphs
From my perspective any structure in engineering and manufacturing is a graph. But a BOM is actually DAG (Directed Acyclic Graph) Managing product structures—whether Bills of Materials (BOMs), Digital Threads, or multi-view product data models—requires a system that can handle complex hierarchical relationships efficiently. Traditional SQL-based PLM systems struggle with the inherent complexity of these relationships, relying on costly and performance-intensive JOIN operations. In contrast, graph databases, such as Neo4j can offer a more natural and efficient way to represent and traverse product structures.
There is an important differentiation- graph model can be created using RDBMS and many PLM vendors are actually do so. The question is will it solve the problem of data management of complex structures and provide full spectrum of graph advantages to BOM and PLM.
Unlike relational databases that store data in rigid tables and require complex queries to retrieve hierarchical information, graph databases store relationships as first-class entities. This architectural difference makes graph databases particularly suited for managing BOMs and other structured engineering data. Let’s explore why this approach is superior for modern product lifecycle management (PLM) and how it enhances efficiency, scalability, and flexibility.
Native Relationship Storage: A Fundamental Advantage
One of the primary reasons graph databases excel at managing product structures is their native handling of relationships. In a traditional relational database, relationships are inferred through foreign keys, and retrieving them often requires expensive JOIN operations. The deeper and more complex a BOM becomes, the more inefficient these operations get.
In contrast, a graph database explicitly stores relationships as edges between nodes, allowing direct traversal. Each part, sub-assembly, or relationship—such as alternates and substitutes—exists as a node or an edge, making queries much faster. For example, finding all components within a large assembly is a simple traversal operation in a graph, while in a relational database, it may require multiple recursive queries and joins.
Efficient Querying of Hierarchical Data
Traditional SQL-based PLM systems struggle with recursive queries, requiring database-specific workarounds such as WITH RECURSIVE in PostgreSQL or CONNECT BY in Oracle. As product structures grow deeper, these queries become increasingly inefficient.
Graph databases, on the other hand, allow for instant navigation through product structures using built-in traversal algorithms like Breadth-First Search (BFS) and Depth-First Search (DFS). For instance, if an engineer needs to determine the full hierarchy of child components within an assembly, a graph database can retrieve the results in near real-time. Similarly, tracking the impact of a part change across multiple assemblies and products is significantly more efficient, as traversal complexity remains nearly constant regardless of the structure depth.
Multi-View BOM Management: Flexibility Beyond Traditional Systems
Modern manufacturing organizations often maintain multiple representations of a BOM, including Engineering BOMs (EBOM), Manufacturing BOMs (MBOM), and Service BOMs. Managing these different perspectives within a traditional relational database is cumbersome because of rigid parent-child relationships. Graph databases naturally accommodate multi-view BOMs by allowing multiple parent-child relationships for each component. OpenBOM’s xBOM service, for example, leverages this approach to enable a flexible, interconnected BOM model where a single component can belong to multiple BOMs. Furthermore, attributes such as quantity, vendor information, and lifecycle status can be stored directly in the edges, ensuring seamless management of product variations and configurations.
Performance Gains for Large and Deep Structures
As product structures become more complex, traditional PLM systems built on SQL databases slow down due to the increasing cost of JOIN operations. Large and deeply nested BOMs, particularly in industries such as aerospace, automotive, and high-tech electronics, can quickly outgrow the performance limits of relational databases.
Graph databases, however, scale efficiently because traversal operations remain consistent in performance, even as the depth of the product structure increases. This makes them particularly well-suited for organizations dealing with intricate multi-level product configurations and massive engineering datasets.
The DAG (Directed Acyclic Graph): The Ideal Model for Product Structures
A particularly effective way to represent product structures is through a Directed Acyclic Graph (DAG). A DAG ensures that relationships between parts, assemblies, and products remain logically consistent and optimized for critical PLM operations.
Directionality Aligns with Product Decomposition
In a DAG, edges between nodes represent relationships such as “contains” or “depends on.” This structure naturally aligns with how product data is used in manufacturing.
- Top-down traversal: Engineers can decompose a product into assemblies and subassemblies, down to individual parts.
- Bottom-up traversal: Analysts can perform a “where-used” analysis to determine which products are affected by a part change.
No Cycles Ensure Logical Consistency
One of the biggest challenges in managing BOMs within relational databases is preventing cyclic dependencies—where a part is inadvertently defined as depending on itself. Cycles in a BOM create paradoxes that break manufacturing logic. A DAG inherently prevents cycles, ensuring that product dependencies remain valid and that infinite loops are avoided.
Supports Advanced PLM Operations
By leveraging a DAG structure, companies can unlock advanced capabilities in their PLM systems, including:
- Effectivity and change impact analysis: Engineers can instantly propagate changes throughout the product structure and assess downstream effects.
- What-if analysis and cost estimation: BOM variants and cost simulations can be easily modeled using weighted graph calculations.
- Digital thread and traceability: By connecting engineering, manufacturing, and supply chain data in a unified graph, companies can establish a comprehensive digital thread.
Efficient Alternative and Substitute Component Management
A DAG also enables advanced BOM scenarios such as managing alternate and substitute components. Instead of rigidly defining a single part relationship, a graph-based approach allows for multiple edges representing interchangeable components, vendor alternatives, and different configurations. This flexibility is essential for supply chain resilience, as manufacturers can quickly switch between component sources when disruptions occur.
The Power of Graph Data Science in Product Data Management
Beyond efficient data storage and retrieval, Graph Data Science (GDS) provides advanced analytical capabilities that are impossible to achieve in relational databases. Graph algorithms can uncover hidden patterns, optimize decision-making, and enhance product lifecycle management in ways that SQL-based systems simply cannot.
For example, centrality algorithms such as PageRank or Betweenness Centrality can identify critical components within a product structure. In a complex BOM, this means quickly determining which parts have the highest impact on multiple assemblies—useful for prioritizing supply chain risk assessments or optimizing maintenance strategies.
Another key function is community detection, which can group similar parts based on shared attributes or dependencies. This helps in standardizing components across product lines, reducing inventory complexity, and improving reuse of parts.
Pathfinding and shortest path algorithms, like Dijkstra’s Algorithm, allow engineers to analyze change impact propagation—for instance, identifying the shortest dependency chain between a modified part and the final product. This is crucial for what-if scenarios, where companies need to assess the cascading effects of engineering changes before implementing them.
Unlike relational databases, where such analyses would require multiple recursive queries and temporary tables, graph databases perform these calculations natively and efficiently, making them a game-changer for next-generation PLM and Digital Thread applications.
What is my conclusion?
The limitations of SQL-based PLM systems in managing complex product structures become apparent as companies demand greater flexibility, scalability, and real-time insights. Graph databases and DAG-based models provide a powerful alternative by offering:
- Fast hierarchical traversal without expensive recursive joins.
- Multi-view BOM flexibility, enabling Engineering, Manufacturing, and Service BOMs to coexist dynamically.
- Impact analysis and dependency tracking with minimal performance overhead.
- Seamless digital thread connectivity across extended enterprise networks.
This is why PLM services capable to leverage native graph-based model—to support the scalability, flexibility, and multi-view complexity required in modern PLM environments. By embracing graph technology, manufacturers can not only streamline their data management but also unlock new opportunities for efficiency and innovation.
Just my thoughts…
Best, Oleg
Disclaimer: I’m the co-founder and CEO of OpenBOM, a digital-thread platform providing Collaborative Workspace with PDM, PLM, and ERP capabilities. With extensive experience in federated CAD-PDM and PLM architecture, I’m advocates for agile, open product models and cloud technologies in manufacturing. My opinion can be unintentionally biased.
