PLM technology can’t stand still—real innovation demands 10× improvements, not fleeting wins from pretty dashboards or one-off “out-of-the-box” features. Just as parametric 3D modeling transformed CAD, OpenBOM’s core graph modeling and graph database form the foundation for the next leap in PLM. SQL is ideal for transactional, tabular records, but when the truth lies in connections—multi-BOMs, lifecycles, and supplier networks—graph models excel.
Introduction — Legacy SQL Roots vs. Connected Products
Product Lifecycle Management (PLM) emerged from the early digital transformation of engineering and manufacturing. It was built during an era dominated by relational databases — structured, transactional, and optimized for predictable data. For decades, SQL-driven PLM systems powered the product record at large OEMs, ensuring control, governance, and traceability.
But the world has changed.
Products are no longer simple assemblies of parts; they are connected systems — blending electronics, software, mechanical design, and supply chain intelligence. Teams are distributed. Data is dynamic. Suppliers, contractors, and manufacturers form digital networks that exchange information continuously.
The old PLM model — static tables, complex object data models schemas using SQL, heavy joins — can’t keep up with this complexity. Legacy PLM systems can move to the cloud, but when they carry the same underlying relational structure, they still fail to model the relationships that now define modern products.
As I’ve written before in Beyond PLM, “The future of PLM isn’t just about moving old systems to the cloud — it’s about rethinking how data connects.”
The challenge for the next generation of PLM isn’t storage; it’s understanding relationships across product structures, configurations, changes, and companies. That’s where graph data models come in.
SQL vs. Graph — What’s Actually Different
To appreciate why graph matters, we need to understand the limitations of SQL.
In a traditional relational system, you define object models with relational tables behind that to model documents, items, BOMs, suppliers, revisions. The RDBMS schemas use foreign keys for connections. To answer even simple questions like “Where is this part used?” or “What’s the cost impact of changing this component?”, the system must perform multiple joins across those tables and run heavy SQL queries. The larger database – more complex queries.
Each new dependency adds more joins — slowing performance and increasing fragility. This works for local company scale and more predictable structures but becomes inefficient when you’re managing data of very complex products or create a platform serving multiple companies with their suppliers and contractors. Complex product data, multi-level, multi-view BOMs that change daily and stretch across multiple systems is a killer for SQL based architecture. .
A graph database flips that logic. Instead of storing data in tables, it stores nodes (items, assemblies, suppliers, documents) and edges (relationships) directly. The connections are as important as the entities themselves.
The result: instead of JOINs, you traverse.
Instead of flat tables, you navigate networks — just like how products, organizations, and supply chains really work.
When you ask “If I change this part, what’s impacted?”, the graph can trace the connections in milliseconds — across EBOMs, MBOMs, alternates, suppliers, and lifecycle states — without flattening data or precomputing views.
Advantage #1 — Relationship-First Modeling for Multi-BOM
In SQL, relationships are a byproduct; in a graph, they are the foundation.
Modern products exist in multiple overlapping configurations — engineering BOM, manufacturing BOM, service BOM, procurement structures, and configuration variants. Managing them with traditional tables means duplicating data and synchronizing between versions.
Graph models handle this natively.
Each product, subassembly, or component is a node linked to others by relationships that define structure, usage, or dependency. Alternate or substitute components are simply additional edges. Manufacturing and procurement views are relationships layered on top of the same graph.
This allows OpenBOM to represent xBOM — multiple BOM perspectives — as part of one interconnected model.
A single component can belong to multiple structures simultaneously, and any change automatically propagates through its relationships.
The benefit is both technical and practical:
- No more complex SQL schemas
- No need for endless data updates and complex indexes
- Easy share, real-time consistency across all product views and companies
When your business runs on product structures that are connected in real time, you gain speed and trust.
Advantage #2 — Deep Traversal: Impact, Propagation, Compliance
PLM is about understanding impact — what happens when something changes.
In SQL-based systems, answering that question often requires flattening a hierarchy into a table, performing complex recursive joins, and running slow queries across many levels.
In a graph database, traversal is the engine.
When a part changes, the system can instantly traverse upward and downward to find all connected assemblies, suppliers, or documents.
This ability enables OpenBOM to perform real-time impact analysis, something that’s almost impossible to do dynamically in relational PLMs. Engineers can see not only what changed, but where that change will cascade — across designs, projects, and teams.
Traversal also supports propagation: lifecycle status, compliance tags, or cost updates can automatically move through the graph to all related nodes. This ensures consistency without heavy scripting or batch jobs.
In short: graph turns BOM exploration into a living, interactive capability instead of a static report.
Advantage #3 — Schema Evolution & xBOM Flexibility
Engineering and manufacturing never stop evolving.
New requirements and rules appear constantly. A sophisticated PLM data model designed 20 years ago becomes outdated and requires changes — it often means a database migration or version upgrade.
Graph models, on the other hand, are schema-flexible. You can add new node types, properties, and relationships without restructuring the entire database.
For example, when OpenBOM customers need to introduce new attributes, you can do it in real time and customize each customer data schedule in a multi-tenant data structure – they can do so instantly — because those attributes simply attach as new nodes or edges in the graph.
This flexibility, for example, enables OpenBOM’s xBOM services — engineering, manufacturing, and procurement views built on the same underlying graph. Each view filters and enriches data differently, but all reference the same connected product truth.
Advantage #4 — Federated Digital Thread (Multi-Tenant Collaboration)
Legacy PLM systems assume that all data lives inside one company, one database, and one server. But that assumption no longer fits the modern manufacturing reality.
Today’s products are co-developed by distributed teams and suppliers. Every company is a node in a global network of design, sourcing, and production.
The digital thread must span multiple organizations, not just internal departments. A graph data model, combined with a multi-tenant SaaS infrastructure, makes this possible.
OpenBOM’s federated architecture connects multiple tenants — each representing a company, division, or partner — through reference links rather than data copies. Each participant maintains ownership of their information but can share connected relationships securely with others.
This approach transforms the digital thread from a single internal pipeline into a federated network — a living, multi-company graph of connected product knowledge.Even more the graph OpenBOM manages is becoming a global manufacturing knowledge graph.
It’s not only technically superior; it reflects how modern manufacturing actually works.
Advantage #5 — Graph Analytics & AI on Lifecycle Context
Once product data lives in a graph, new layers of insight emerge through graph data science and AI. Graph algorithms can analyze the topology of your product data to answer deep lifecycle questions:
- Centrality analysis can reveal which parts or suppliers are most critical to product performance or sourcing risk.
- Community detection can uncover natural modular groupings across assemblies.
- Anomaly detection can flag broken relationships or inconsistent attributes before they cause manufacturing errors.
- Path analysis can trace compliance lineage — every dependency from design to final assembly.
These capabilities lay the foundation for AI-assisted PLM, where the system doesn’t just store information — it reasons about it.
At OpenBOM, this foundation is essential for building the next generation of intelligent assistants and product memory agents that will proactively identify risk, suggest optimizations, and connect decision-making across the lifecycle.
Why “Hosted Cloud PLM” Isn’t Enough
It’s tempting to assume that cloud PLM solves all problems. This is what major PLM vendors told everyone. You have “cloud versions” of mature PLM platforms — but not all clouds are equal.
PLM vendors have rebranded their systems as “cloud-based,” but what they actually offer is hosting: the same monolithic SQL platform running on remote infrastructure. It’s single-tenant, complex, and costly.
True cloud PLM requires a multi-tenant, graph-based architecture that enables real-time data sharing, flexible evolution, and continuous delivery.
The difference isn’t cosmetic; it’s fundamental. Hosting old code in AWS doesn’t make it modern. Rebuilding PLM around graph and SaaS principles does.
As I explained in my Beyond PLM article – monolithic PLM was built for control. Today, we need PLM built for connection — and that means rethinking the data model from the ground up.
OpenBOM in Practice — Product Knowledge as a Graph
OpenBOM’s architecture is designed from day one around graph data principles. At its core, every piece of data — an item, property, vendor, or BOM — is a node connected through relationships that reflect real product logic.
This enables:
- Real-time collaboration – multiple users editing simultaneously across shared data structures.
- xBOM views – engineering, manufacturing, procurement perspectives that stay synchronized.
- Impact analysis – instant visibility into how a change propagates through the product graph.
- Multi-tenant sharing – seamless collaboration across teams and companies.
Check our customer stories that speak how OpenBOM customers use the product. Their workflows blend structured engineering discipline with the agility of modern SaaS — managing BOMs, costs, and suppliers as connected data rather than isolated spreadsheets.
OpenBOM’s graph foundation doesn’t just make the platform flexible; it makes it intelligent. Every connection, every dependency, every cost roll-up becomes part of a dynamic, navigable knowledge graph — the digital DNA of the product lifecycle.
Objections & When SQL Still Wins
It’s important to be fair: SQL is not obsolete. Relational databases remain exceptional for transactions, reporting, and financial consistency. When you need strict ACID guarantees, batch analytics, or well-defined tables, SQL is unmatched.
But for connected data — complex relationships, multi-level dependencies, cross-system links — graph models outperform both technically and conceptually.
Therefore, at OpenBOM, we don’t move everything to a graph. OpenBOM data management architecture is polyglot with microservices – we use the right database for a job – graph, NoSQL, SQL, and others- it creates a unique value and characteristics of OpenBOM data modeling architecture: use graphs where relationships matter most.
At OpenBOM, we blend these technologies, using each where it fits — because innovation in PLM isn’t about replacing everything; it’s about choosing the right tool for the right job.
Conclusion — Why It Matters Now
The evolution of PLM is the story of how we manage complexity. In the 1990s, complexity was hierarchical — so we built tables. Today, complexity is relational — so we need graphs.
A relationship-first model gives companies visibility, traceability, and intelligence across their entire product lifecycle. It enables SMBs to move as fast as startups and gives enterprises a foundation for true digital transformation.
Monolithic PLM was built for control. Modern PLM is built for connection.
Graph-based data modeling isn’t just a new technology; it’s a new way of thinking about how product knowledge should flow — across people, processes, and companies.
REGISTER FOR FREE to check how OpenBOM can help or contact us for a meeting.
Best, Oleg
Join our newsletter to receive a weekly portion of news, articles, and tips about OpenBOM and our community.
