PLM Graph Database Impact Analysis: Where-Used, Change Propagation and Neo4j vs Relational BOM Queries

A single engineering change request on a fastener, a connector or a firmware image can touch hundreds of assemblies, dozens of open work orders and several supplier contracts. The person approving that change usually has one question: what else does this break? In most product lifecycle management (PLM) deployments the honest answer is “run the where-used report and wait,” and the report is a recursive join over a bill of materials (BOM) table that was never designed to be asked that question quickly or repeatedly.

PLM graph database impact analysis reframes the problem. A BOM is a directed acyclic graph (DAG), not a tree, and change impact is a reachability query over that graph, filtered by time and configuration. That framing is why graph engines such as Neo4j keep appearing in PLM architecture reviews, and why a well-tuned relational schema is still a serious competitor.

You will leave with a graph schema for parts, usage links, effectivity and change objects, working Cypher and SQL for where-used and blast-radius queries, a cost model for recursive common table expressions (CTEs) versus traversal, and a decision rule for when each engine wins.

What this covers: the BOM as a DAG, a property-graph schema, where-used and change propagation queries, effectivity modelling, relational versus graph cost mechanics, a reference architecture, failure modes, and a practical checklist.

Context and Background

Every PLM system stores the same core structure: items (parts and assemblies), revisions of those items, and usage relationships that say “assembly A revision C uses part B, quantity 4.” Commercial platforms wrap this in their own object models, but underneath sits a relational database with a parent-child link table. Questions that walk one level are cheap. Questions that walk an unknown number of levels, such as “every finished good that contains this bearing, at any depth,” require recursion.

Recursion is where the pain starts. A single product structure for an aircraft, a car or an industrial machine can have many levels of indented BOM, and the same sub-assembly is reused across many parents. That reuse is what makes the structure a DAG: a node can have several parents, but no node can be its own ancestor. The distinction matters because a tree-oriented tool (an indented outline, a materialised path column) silently duplicates shared sub-assemblies or loses the second parent entirely.

Change management adds a second dimension. Our guide to engineering change management with ECR, ECO, ECN, effectivity and the OSLC digital thread explains how a change moves from request to order to notice. The graph question sits one step earlier: before anyone signs an ECO, someone has to compute its blast radius, meaning the set of items, configurations, documents, suppliers and downstream consumers that the change reaches.

A third dimension is the engineering-to-manufacturing handoff. The same part is a node in an engineering BOM (EBOM) and a different kind of node in a manufacturing BOM (MBOM). We covered that transformation in EBOM to MBOM transformation across PLM and ERP, and impact analysis must follow the transformation links, otherwise a change that is safe in engineering becomes a surprise on the shop floor.

Why this is a graph problem now

Two things changed. First, graph query languages matured: Neo4j’s Cypher gained quantified path patterns in the 5.x line, and the International Organization for Standardization published ISO/IEC 39075 (the GQL graph query language) in 2024, alongside the property graph query extension (SQL/PGQ) in the SQL:2023 revision. Second, the volume and coupling of PLM data grew as software, electronics and mechanical content converged in one product structure. The result is more nodes, more reuse, and more people asking ad hoc reachability questions.

None of this means relational databases cannot answer the question. PostgreSQL’s WITH RECURSIVE, the SQL standard’s recursive CTE, handles hierarchical traversal and, since PostgreSQL 14, offers SEARCH and CYCLE clauses for ordering and cycle detection. The honest comparison is about operational shape, not capability, and we will keep that comparison grounded in mechanisms rather than slogans.

The BOM as a Directed Acyclic Graph: A Reference Schema

A BOM graph model represents each item revision as a node and each “uses” relationship as a directed edge carrying quantity, find number and effectivity properties. Where-used is a reverse traversal along those edges; a “what does this contain” explosion is a forward traversal. Both are reachability queries over a DAG.

Figure 1: A property-graph schema for PLM impact analysis. Item revisions connect through USES edges that carry quantity and effectivity; change objects connect through AFFECTS edges.

Figure 1 shows the minimum viable schema. It has five node labels and four relationship types, and every extra concept you are tempted to add should earn its place by serving a query you actually run. The long description: an Item represents the abstract part number, an ItemRevision represents a released or in-work state of that item, a USES edge links a parent revision to a child item or revision, a Change node (ECR or ECO) points at the revisions it AFFECTS, and an Effectivity structure bounds when and where an edge applies.

Items, revisions and the choice of edge target

The first design decision is whether a usage edge points at a child item or at a specific child revision. Both appear in the field. Pointing at the item (“this assembly uses part 1234, latest released”) matches how many PLM products resolve structure at query time with a revision rule. Pointing at a revision is explicit and stable, but a revision bump on a leaf part forces edits all the way up the structure unless you automate it.

For impact analysis I recommend a hybrid. Store edges item-to-item with an optional pinned revision property, and store the resolution rule (latest released, as-of date, or explicit pin) on the traversal, not on the data. This keeps the graph small, because revisions multiply nodes by the average revision count, and it lets the same graph answer both “what uses this part number” and “what uses this exact revision.”

Usage edges carry the business logic

In a property graph, an edge is a first-class record with properties. That is the feature that makes the BOM natural to model: a USES edge can hold qty, findNumber, unitOfMeasure, referenceDesignators, optional, and the effectivity bounds. A relational equivalent is a link table with the same columns and two foreign keys, so the information content is identical. The difference is how the engine stores and walks it, which we turn to in the cost section.

A minimal relational definition looks like this:

CREATE TABLE item (
  item_id      BIGINT PRIMARY KEY,
  part_number  TEXT NOT NULL UNIQUE,
  item_type    TEXT NOT NULL
);

CREATE TABLE bom_usage (
  usage_id     BIGINT PRIMARY KEY,
  parent_id    BIGINT NOT NULL REFERENCES item(item_id),
  child_id     BIGINT NOT NULL REFERENCES item(item_id),
  qty          NUMERIC NOT NULL,
  find_number  INT,
  eff_from     TIMESTAMPTZ NOT NULL DEFAULT '-infinity',
  eff_to       TIMESTAMPTZ NOT NULL DEFAULT 'infinity',
  eff_unit_lo  BIGINT,
  eff_unit_hi  BIGINT
);

CREATE INDEX bom_usage_child_idx  ON bom_usage (child_id, eff_from, eff_to);
CREATE INDEX bom_usage_parent_idx ON bom_usage (parent_id, eff_from, eff_to);

The equivalent graph creation in Cypher, shown as a single sample statement, is:

MERGE (p:Item {partNumber: 'ASM-1000'})
MERGE (c:Item {partNumber: 'BRG-6204'})
MERGE (p)-[u:USES {findNumber: 20}]->(c)
SET u.qty = 2,
    u.effFrom = datetime('2026-01-01T00:00:00Z'),
    u.effTo = datetime('9999-12-31T00:00:00Z');

Note the two indexes on the relational side. A where-used query walks child to parent, and a explosion walks parent to child, so you need both directions indexed. Forgetting the child-side index is the single most common reason a relational where-used report is slow.

Why not just a tree?

Many teams model the BOM with a materialised path or nested sets because those make downward explosion cheap. They fail the moment a sub-assembly has two parents, which is the normal case for standard hardware, harnesses, firmware modules and platform sub-assemblies. A materialised path stores one path per node, so a shared node needs one row per parent. That duplicates data, and an update to the shared node must touch every copy. A DAG representation stores the shared node once and lets many edges point at it.

The practical consequence is that where-used on a tree-shaped model is either wrong (it only reports one parent) or expensive (it scans copies). Treat the BOM as a DAG from day one, and let the engine’s query layer enforce acyclicity, which we discuss under failure modes.

Where-Used and Change Propagation Queries

Where-used analysis answers “which parents contain this item, directly or indirectly.” In a graph it is a variable-length reverse traversal from the changed node to every ancestor, optionally filtered by effectivity. Change propagation extends it: from the set of affected ancestors, follow additional edge types to documents, suppliers, work orders and software builds.

The three queries below progress from simple to realistic. All three are examples written for this post to show the shape of the solution; the labels, property names and thresholds are illustrative and not taken from any specific PLM product.

Query 1: unbounded where-used

In Cypher, a variable-length pattern uses an asterisk with optional bounds on the relationship. The Neo4j manual documents variable-length paths for this purpose, and Neo4j 5 also offers quantified path patterns that let you put predicates on every hop. The classic form is:

MATCH (changed:Item {partNumber: 'BRG-6204'})<-[:USES*1..]-(ancestor:Item)
RETURN DISTINCT ancestor.partNumber AS partNumber, ancestor.itemType AS type
ORDER BY partNumber;

The same question in PostgreSQL uses a recursive CTE. The non-recursive term seeds the working set with direct parents; the recursive term joins the working set back to the usage table:

WITH RECURSIVE whereused (item_id, depth) AS (
  SELECT u.parent_id, 1
  FROM   bom_usage u
  JOIN   item c ON c.item_id = u.child_id
  WHERE  c.part_number = 'BRG-6204'
  UNION
  SELECT u.parent_id, w.depth + 1
  FROM   whereused w
  JOIN   bom_usage u ON u.child_id = w.item_id
)
CYCLE item_id SET is_cycle USING path
SELECT DISTINCT i.part_number, i.item_type
FROM   whereused w
JOIN   item i ON i.item_id = w.item_id
WHERE  NOT w.is_cycle
ORDER BY i.part_number;

Two details deserve attention. Using UNION rather than UNION ALL discards duplicate rows between iterations, which collapses the diamond patterns a DAG produces; without it, a node reachable by ten paths is expanded ten times. And the CYCLE clause (available from PostgreSQL 14) marks rows whose key already appeared on their own path, so corrupted data that introduced a loop does not run forever.

Query 2: where-used filtered by effectivity

Raw reachability over-reports. If the bearing is used in a 2024 variant that is no longer built, the engineer approving the change does not need it in the blast radius, or at least needs it labelled differently. Effectivity turns the traversal into a filtered one. In Cypher, the predicate sits on the relationship inside a quantified path pattern:

WITH datetime('2026-12-01T00:00:00Z') AS asOf
MATCH (changed:Item {partNumber: 'BRG-6204'})
MATCH p = (changed)
  ( (a)<-[u:USES]-(b)
    WHERE u.effFrom <= asOf < u.effTo ){1,}
  (top:Item)
WHERE NOT EXISTS { (top)<-[x:USES]-() WHERE x.effFrom <= asOf < x.effTo }
RETURN top.partNumber AS topLevel, length(p) AS depth;

This returns the effective top-level products that contain the part on the as-of date, because the NOT EXISTS clause keeps only nodes with no effective parent. The pattern is a sketch of the technique: check the current Cypher manual for the exact quantified path pattern grammar in your Neo4j version before relying on it, since syntax rules for inline WHERE clauses and chained comparisons differ across releases.

The relational equivalent adds the date predicate to both the seed and the recursive join:

-- inside the recursive term
JOIN bom_usage u ON u.child_id = w.item_id
                AND u.eff_from <= :as_of AND :as_of < u.eff_to

Because the predicate is inside the join, the optimiser can use the composite index (child_id, eff_from, eff_to) to prune at every level instead of filtering a large intermediate result at the end. This is the single most valuable relational optimisation for where-used.

Query 3: ECO blast radius

An ECO blast radius is not just ancestors. It is the union of several traversals, each with its own stopping rule:

Ancestors through USES, bounded by effectivity and by the product configurations in scope.
Sibling impacts, such as parts that share a drawing, a specification or a software module with the changed item.
Downstream manufacturing objects: MBOM lines, routings, work centres and open work orders linked from the EBOM node.
Commercial objects: supplier items, contracts, inventory positions and open purchase orders.
Verification objects: test plans, simulation models and certification evidence that cite the changed revision.

MATCH (eco:Change {number: 'ECO-2026-0412'})-[:AFFECTS]->(r:ItemRevision)<-[:REVISION_OF]-(i:Item)
CALL (i) {
  MATCH (i)<-[:USES*0..]-(a:Item)
  RETURN collect(DISTINCT a) AS ancestors
}
WITH eco, i, ancestors
UNWIND ancestors AS a
OPTIONAL MATCH (a)-[:REALIZED_AS]->(m:MbomLine)<-[:CONSUMES]-(wo:WorkOrder {status: 'OPEN'})
OPTIONAL MATCH (a)<-[:SUPPLIES]-(s:SupplierItem)
RETURN eco.number AS eco,
       count(DISTINCT a)  AS impactedItems,
       count(DISTINCT wo) AS openWorkOrders,
       count(DISTINCT s)  AS suppliers;

The point of this query is not the syntax, which depends on your version, but the shape: one reachability step to compute the ancestor set, then several bounded one-hop expansions from that set. The first step is the expensive one. The rest are index lookups. Our article on configurable products, CPQ constraint solving and the 150 percent BOM explains why the ancestor set is often larger than reality: a 150 percent BOM contains every optional branch, so you must intersect the traversal with the configuration rules to avoid reporting impact on variants nobody can order together.

Figure 2: Sequence of an ECO impact request. The graph store computes reachability; PLM and ERP link resolvers enrich the result before the report is ranked.

Figure 2 shows the runtime flow. The engineer submits an ECO draft; the PLM service resolves the affected revisions; the graph store computes the ancestor closure under the chosen as-of date and configuration scope; link resolvers attach MBOM, supplier and work-order context; and the service returns a ranked report. Ranking is a product decision, but severity heuristics such as depth, safety classification of the ancestor, and number of open orders work well as a starting point.

Direction matters: explosion versus where-used

An explosion goes from a parent to its children and typically terminates at leaf parts, so its size is bounded by the product structure. A where-used goes from a child to its parents and can fan out wildly for common hardware: a standard M6 screw may be reachable from nearly every top-level product. This asymmetry explains why where-used reports are the slowest queries in many PLM systems, and why you should cap reporting with a “top-level products only” mode and a count before returning rows.

Modelling Effectivity, Revisions and Configurations

Effectivity states when, where and for which units a usage edge is valid: a date range, a serial or lot range, or a configuration condition. Model it as properties on the edge, not as extra nodes, unless several edges share one effectivity rule that business users manage as an object.

Effectivity is the hardest part of making BOM graph queries correct, because it is the part where engineering intent lives. The change-management post linked above covers the governance side. Here is the data side.

Three effectivity styles

Date effectivity uses effFrom and effTo on the edge. It is simple, indexable and fine for planned introductions. Its weakness is that production does not follow calendars: a cut-in date that slips by a week silently changes which units are affected.

Unit (serial or lot) effectivity uses a range of unit numbers, such as unitLo and unitHi. It is precise for build-to-order products and aerospace, and it makes the traversal take the unit as an extra parameter. A where-used answer then becomes “which units in the field contain the old revision,” which is exactly what a retrofit or recall needs.

Configuration (option) effectivity attaches a boolean condition over options to the edge, for example region = EU AND package = Premium. The traversal then needs a configuration context and an evaluator for the condition. Graph databases do not evaluate these expressions natively at scale, so evaluate them in the application layer or precompute a resolved configuration subgraph.

Overlapping ranges are data bugs, not features

A well-formed BOM has, for a given parent, find number and unit, at most one effective child edge. Overlaps produce double counting in quantity roll-ups and ambiguous impact. Add a validation job that detects overlaps, and run it at release time rather than at query time. In PostgreSQL you can enforce this with an exclusion constraint on a range type; in Neo4j you need a validation query or a plugin-level check because the database has no declarative equivalent for temporal overlap.

Revisions: resolve late

Resolve revisions at query time with an explicit rule instead of storing a revision on every edge. Three rules cover almost every case: latest released as of a date, the revision pinned by a baseline, and the working revision for a change in progress. Keep the rule an input of the query, which also gives you what-if analysis: run the blast radius twice, once against the released baseline and once against the baseline plus the draft ECO, and diff the results.

Baselines as subgraph snapshots

A baseline is a frozen view of the structure, such as the as-designed state at a design review. Storing a copy of the entire graph per baseline is wasteful. Store baselines as lightweight membership records: a Baseline node with edges to the specific revisions it pins, and let the traversal rule “pinned by baseline X” read from that. This is the same idea that source control systems use for tags, and it keeps storage proportional to the number of pinned objects rather than the number of edges.

Neo4j vs Relational BOM Queries: Cost Mechanics

A recursive CTE and a graph traversal compute the same reachability, but they pay for it differently. The relational engine pays an index lookup and a join per hop per frontier row. A native graph engine follows stored relationship pointers from node to node. The gap depends on depth, fan-out, indexing and caching, so measure on your own data before deciding.

Figure 3: How the two engines execute a where-used query. The recursive CTE iterates a working table through index joins; the graph engine expands a frontier by following adjacency pointers.

Figure 3 contrasts the two execution models. The relational path starts with a seed set, joins it to the usage table using the child-side index, deduplicates, and repeats until the working table is empty. The graph path starts at the node, reads its incoming relationships from the node’s adjacency structure, and repeats for each newly reached node, tracking visited nodes to avoid repeated expansion.

What the cost actually depends on

Let d be the depth of the BOM, f the average number of parents per node (the where-used fan-out), and V the number of distinct ancestors. A deduplicating traversal in either engine touches each reachable edge a bounded number of times, so the work scales with the number of edges in the reachable subgraph, not with the size of the whole database. This is the part of the folklore that is true in both directions: neither engine should scan the whole structure for a where-used query if indexes are correct.

The differences are in the constants and the failure modes:

Per-hop cost. A B-tree index lookup costs logarithmic time in the table size, plus buffer access. An adjacency pointer follow is a constant-time read once the page is cached. For shallow traversals on a warm cache the gap is small; for deep traversals over many hops the lookups add up. The magnitude is workload dependent, and I do not cite a universal multiplier because published comparisons vary widely with schema, hardware and tuning.
Deduplication. UNION in a recursive CTE has to hash or sort rows each iteration. A graph engine tracks visited nodes in the traversal state. Both are fine; the CTE just does it with more relational machinery.
Path semantics. Cypher enforces relationship uniqueness within a single MATCH pattern (a path cannot reuse the same relationship), which gives finite results on cyclic data but can still enumerate an enormous number of distinct paths on a DAG with heavy reuse. Always return DISTINCT nodes rather than paths unless you need the paths.
Planner visibility. The PostgreSQL planner treats a recursive CTE as an opaque loop with a rough row estimate, which limits its ability to reorder joins inside the recursion. Index design therefore matters more than usual.

The path explosion trap

Both engines can be hurt by the same pathology: counting paths instead of nodes. In a DAG with heavy reuse, the number of distinct paths from a leaf to the roots can be vastly larger than the number of ancestor nodes. If your query materialises paths (a RETURN p in Cypher or a path-array column in SQL), it enumerates all of them. The remedy is a set-based formulation: expand the frontier level by level, keep a visited set, and only ever return distinct nodes. In SQL, that means UNION rather than UNION ALL with the path-array carried only when cycle detection needs it.

When SQL wins

Relational wins when the BOM data already lives in the PLM system’s database, when queries are shallow or well-bounded, when the team has strong SQL skills, and when the data must stay transactionally consistent with the rest of the PLM objects. A single database also means one backup story, one access control model and no synchronisation lag. For many mid-size product structures, a correctly indexed recursive CTE returns where-used answers fast enough for interactive use. Illustratively, if your deepest chains are under about ten levels and your largest where-used set is in the low thousands of rows, there is little reason to introduce a second database.

PostgreSQL also offers extension routes. Ltree-style materialised paths speed up tree-shaped subsets, and the SQL:2023 property graph query extension (SQL/PGQ) defines a graph pattern syntax that a relational engine can evaluate over ordinary tables. Support varies by vendor and version, so verify it in the specific product you run rather than assuming it.

When a graph database wins

A graph store earns its place when the questions are multi-hop and heterogeneous: traverse from a part through BOM edges, then through requirement links, then through simulation results, then to supplier items, all in one query. Expressing that in SQL means a chain of joins and unions across many tables with recursion in the middle. In Cypher it is one pattern. Graph also wins when analysts need ad hoc exploration, because the model is closer to how engineers draw the problem on a whiteboard, and when the structure is far larger than the relational system can answer quickly after tuning.

The cost is a second system. You must feed it, secure it, monitor it, and reconcile it with the system of record. Neo4j also brings licensing and operational decisions that depend on edition, clustering needs and deployment target; check the vendor’s current documentation and pricing, because they change between releases.

A decision matrix

Criterion	Recursive CTE in the PLM RDBMS	Native graph database
Typical where-used depth	Shallow to moderate	Moderate to very deep
Multi-hop across object types	Verbose joins and unions	One pattern
Transactional consistency with PLM	Native	Needs sync or dual write
Operational footprint	Existing database	Additional cluster
Ad hoc exploration by engineers	SQL skills needed	Visual graph tools help
Temporal and effectivity logic	Range types, exclusion constraints	App-side or property filters
Query predictability	Planner opaque in recursion	Depends on pattern and indexes
Standards path	SQL:2023 SQL/PGQ	ISO/IEC 39075 GQL

No row of this table decides the question alone. Weight the rows by the questions your users actually ask. If 90 percent of requests are single-level where-used with effectivity filtering, the relational column wins. If your roadmap includes digital thread analytics that join requirements, simulation and field data, the graph column starts to dominate.

A Reference Architecture for Graph-Based Impact Analysis

The safest pattern keeps the PLM system as the system of record and builds the graph as a derived, rebuildable projection fed by change data capture. The impact service queries the projection, enriches results from authoritative sources, and never writes back to the graph outside the pipeline.

Figure 4: Reference architecture. Sources feed a change-data-capture pipeline into a graph projection; an impact service answers ECO, procurement and digital twin consumers.

Figure 4 shows five stages. Sources include the PLM database, the ERP, the requirements tool and the simulation data manager. A change-data-capture (CDC) pipeline streams inserts, updates and deletes into a mapper that turns rows into nodes and edges. The graph projection holds the result. An impact service exposes endpoints such as “where used,” “blast radius for ECO” and “what-if with draft change.” Consumers include the change board, procurement and planners, and digital twin synchronisation services.

Why a projection and not a migration

Replacing the relational BOM with a graph as the primary store sounds appealing and is rarely wise. PLM products carry lifecycle state, access control, vaulting, workflow and audit logic on top of the BOM tables. Rewriting all of that onto a graph store is a multi-year project with weak payoff. A projection gives you the graph’s query strengths while the PLM keeps its authority.

The consequence is eventual consistency. The graph lags the source by the pipeline latency. For impact analysis during change review this is acceptable if you surface the projection’s watermark, meaning the last source transaction it has applied. Show it in the report: “computed from data as of 10:42:07.” For approvals, a stale graph is a risk, so gate release actions on a freshness check or a final verification query against the source.

Mapping rows to graph elements

Keep the mapping declarative. A table for items becomes Item nodes keyed by a stable identifier (not the part number, which can change under renumbering). The usage table becomes USES edges with their properties. Change objects and their affected-item lists become Change nodes and AFFECTS edges. Run a periodic full reconciliation that counts nodes and edges per label and compares them with source counts, and a sampled deep check that compares neighbourhoods for random items. When the projection diverges, rebuild it rather than patching it.

Idempotent upserts and ordering

CDC events can arrive duplicated or out of order, so the writer must be idempotent. Use MERGE on the stable key and apply updates only if the event’s source version is newer than the stored one. Process events for one parent item in order by partitioning the stream on the parent identifier. Without these two rules you will eventually see an edge that was deleted in the source come back to life in the graph, which is a very confusing bug to debug during an ECO review.

Digital twin and downstream consumers

The impact graph is also valuable outside change control. A digital twin that mirrors a fleet of products needs to know which units contain which revisions, so that a change can be traced to the physical assets it affects. Joining the BOM graph with an as-built record for each serial number lets the twin answer “which deployed units contain the revision being changed,” which is the retrofit question. Treat as-built data as another node type linked by BUILT_FROM edges, and keep it in the same projection only if its volume is manageable; very large fleets may justify a separate store keyed by the same identifiers.

Trade-offs, Gotchas, and What Goes Wrong

Graph projections fail in specific, predictable ways. Knowing them in advance is cheaper than discovering them during a release freeze.

Cycles in supposedly acyclic data. A BOM must be a DAG, but data entry errors, bad migrations and cross-tool synchronisation can create a loop where an assembly ends up inside itself. A Cypher variable-length pattern with relationship uniqueness will terminate, but it may return nonsense ancestors; a recursive CTE without cycle protection can run until a resource limit kills it. Add a cycle detector to the ingest pipeline, and use the CYCLE clause in PostgreSQL queries as a safety net. Reject the load rather than silently dropping edges.

Supernodes. A standard fastener may have many thousands of parents. Traversing into that node is cheap, but expanding it in a graph database touches every relationship, and many analysts will accidentally start a query there. Put guards in the impact service: a degree check before expansion, a cap on result sizes, and a “count only” mode. Consider modelling very common hardware as a catalogue relationship that is excluded from default where-used.

Effectivity logic drift. If effectivity rules live both in the PLM and in the graph query layer, the two will diverge. Treat the PLM as the single definition of effectivity and project resolved values, or evaluate effectivity in one shared library. A report that disagrees with the PLM’s own where-used erodes trust faster than a slow report.

Over-reporting and alert fatigue. Reachability is a superset of real impact. If every ECO shows hundreds of items, reviewers stop reading. Rank by severity, collapse by top-level product, and show the shortest path that explains why each item appears. Explanations are what turn a graph result into a decision.

Treating performance claims as portable. Vendor blog posts and conference talks reporting large speedups of graph over relational were measured on specific schemas, hardware and warm caches. They are not a guarantee for your data. Build a representative benchmark with your deepest assemblies, your most reused parts and a realistic concurrency level, and test both engines tuned by people who know them.

Security and export control. The graph can reveal structure that individual users are not permitted to see. A user without access to a classified sub-assembly must not learn it exists through a where-used result. Enforce authorisation in the impact service by filtering nodes and edges against the PLM’s access control, and consider whether partial results can leak information through counts.

Semantics of deletion. Released structure is rarely deleted; it is superseded. If your pipeline treats a status change as a delete, the graph will lose history. Model lifecycle state as a property and filter on it.

Practical Recommendations

Start from the questions, not the technology. List the ten queries your engineers, planners and quality teams ask most often, mark which are single-hop, which are multi-hop within the BOM, and which cross object types. If almost all are within the BOM and shallow, tune the relational schema first: add the child-side composite index, rewrite the where-used as a deduplicating recursive CTE with cycle protection, and measure again. You may not need a second system.

If the cross-object questions dominate, run a bounded pilot. Pick one product family, project its BOM, changes and one adjacent domain (manufacturing or suppliers) into a graph, and compare the blast-radius report with what planners produce by hand for three historical ECOs. The measure of success is whether the graph found impacts that people missed and whether reviewers trusted the explanations.

Keep the PLM as the source of truth, treat the graph as rebuildable, and expose a small, stable API rather than letting users write queries against production. Publish the freshness watermark with every answer. Treat all performance figures in this article as illustrative, and replace them with your own measurements.

Checklist before go-live:

Stable identifiers for items independent of part numbers.
Indexes on both directions of the usage relationship, with effectivity columns.
Cycle detection at ingest and in queries.
Idempotent, ordered CDC with a visible watermark.
Degree and result-size guards for supernodes.
Effectivity defined once, validated for overlaps at release.
Access control enforced in the impact service.
A reconciliation job comparing counts and neighbourhoods against the source.
A what-if mode that diffs baseline versus baseline plus draft ECO.
A benchmark using your own deepest and most reused assemblies.

Frequently Asked Questions

What is where-used analysis in PLM?

Where-used analysis finds every parent assembly and product that contains a given part, directly or through intermediate assemblies. Engineers run it before changing, obsoleting or substituting a part to see what the change reaches. Technically it is a reverse traversal of the bill of materials, filtered by revision rules, effectivity dates or serial ranges, and often limited to top-level products or active configurations so the answer stays readable.

Is a bill of materials a tree or a graph?

A BOM is a directed acyclic graph. It looks like a tree when drawn as an indented outline, but shared sub-assemblies and standard parts have several parents, so a strict tree would duplicate them. Because no assembly can contain itself, the graph has no cycles. Modelling it as a DAG keeps shared nodes single, makes where-used correct, and prevents update anomalies on reused components.

Is Neo4j faster than SQL for BOM queries?

It depends on depth, fan-out, indexing and caching. A native graph engine follows stored relationship pointers, which tends to help on deep, multi-hop traversals, while a well-indexed recursive CTE is competitive on shallow, bounded queries. No universal multiplier applies. Build a benchmark with your own deepest assemblies and most reused parts, tune both engines properly, and compare latency under realistic concurrency before committing to a second database.

How do you model effectivity in a graph database?

Store effectivity as properties on the usage relationship: date range, serial or lot range, and where needed a configuration condition. Filter inside the traversal so pruning happens at every hop. Validate that effective ranges do not overlap for the same parent, find number and unit, and resolve revisions at query time using an explicit rule such as latest released, baseline pinned or working revision.

How does a graph help with engineering change impact?

It turns an engineering change into a reachability query. From the revisions an ECO affects, the graph computes ancestors through BOM edges, then expands one hop into manufacturing lines, work orders, suppliers and verification evidence. The result is a ranked blast radius with a path explaining each hit, and a what-if mode can compare released structure against released plus draft change.

Should the graph replace the relational PLM database?

Usually not. PLM databases carry lifecycle state, access control, vaulting, workflow and audit trails that are costly to rebuild. The safer pattern is a rebuildable graph projection fed by change data capture, with the PLM as the system of record. Show a freshness watermark with every result and verify against the source before releasing a change.