Something unusual is happening in the conversation about the future of PLM. We seem to be moving toward less database and more database at the same time. For the last few months, I had multiple discussions about the future of PLM, the vision for new platforms, the need for better PLM implementations, the role of OCM, and of course a lot about the role AI takes in the future.
In my article today, I want to bring these multiple visions together and give you my perspective on what I can see in the future PLM trajectories. We might not end it in a single article and might move to a series of articles. Let’s see.
Vision #1: AI eats the database
On one side is the AI-native vision. Agents read documents, tables are flattened into text, information is embedded into vector stores, and context windows assemble whatever a task needs. AI generates applications on the fly, calls tools, and increasingly keeps its own memory of previous interactions. Take this far enough and a provocative question appears: do we need traditional databases at all?
I heard this question raised almost explicitly in a recent episode of Conversations in Action, titled, fittingly, “Do Databases Have a Future?”, in which John Werner and Alex Wissner-Gross talk with Michael Stonebraker, Turing Award winner and one of the pioneers of the relational database (we should thank him for Ingres and Postgres). Foundation models don’t operate on tables. They operate on tokens and long strings. It is not crazy to ask whether LLMs are the start of an architecture in which tables, and eventually databases, stop being the fundamental primitive of enterprise software. A primitive version of that architecture already exists: pull information from many sources, turn it into text, put it in the model’s context, and let the AI find the connections.
Vision #2 says the PLM database was never big enough
At almost the same time, engineering software is producing the opposite vision. Doug Macdonald’s Future Platform for Hardware Engineering report opens with a criticism of legacy PLM I largely share: it was too narrow, centered on mechanical design data, and never captured enough of the lifecycle. The FPHE answer is to expand scope substantially. Requirements, hardware, software, BOMs, manufacturing, sourcing, verification, service, and, most importantly, the relationships between information created by different disciplines and systems, all managed through one future platform.
The argument gets stronger when AI enters. In the FPHE view, the platform is what gives agents the information access and context they need. A network of independent AI tools can solve individual problems, but it lacks the persistence of storage and consistency of process a common platform provides.
“Bigger database is better” is not Doug’s phrase, and I want to be fair to the report. But if I compress its architectural implication into one line, it is this: the PLM database was too narrow, centered on MCAD. It wasn’t too big. It wasn’t big enough. More complete product context requires a bigger platform, and underneath it, a bigger database.
Vision #3 says the PLM database is fine and the implementation is broken
There is a third position, and experienced practitioners such as Andreas Lindenthal have articulated it well. Maybe nothing is fundamentally wrong with the PLM database idea. Modern platforms already manage items, documents, structures, configurations, revisions, changes, processes, relationships, lifecycle states, and access control. In principle, a unified PLM database provides exactly the consistency that fragmented domain applications cannot.
From this perspective the problem is not architecture but implementation. Data wasn’t cleaned. Processes weren’t defined. Governance was weak. Implementations never reached their intended scope. Systems were customized until they could not be upgraded. And then the industry blamed the model instead of the execution. Andreas has made two further points that sharpen this camp. A unified PLM database avoids the proliferation of integrations that separate domain databases create. And PLM should remain the governed system of record underneath AI, with AI becoming a system of intelligence on top, provided the underlying data, governance, and processes are solid.
There is real merit here. Maybe we don’t need a new product information architecture. Maybe we need to finally make PLM work as intended.
So we have three answers to one question. AI-native: databases matter less. FPHE: the platform must manage far more. Traditional PLM: the architecture is capable enough, fix the implementation. I don’t think any of the three is complete, and the Stonebraker episode is what helped me see why.
AI does not make structure disappear
One of Stonebraker’s arguments is disarmingly simple: don’t throw away structure you already have. He describes a common agentic pattern. Two structured sources are converted to text, both go into the model, and the LLM effectively performs the join. His objection is obvious once you hear it. Why destroy the structure first? If you have two tables and need a join, leave them as tables and do a structured operation. Converting them to text discards information the database already understands.
That maps directly onto PLM. A BOM is not a document. A configuration is not a paragraph. A revision chain is not prose. Effectivity is not text. The link between a requirement, a design item, and a verification test is not a set of words that happen to sit near each other. We can flatten all of it into text and hand it to an LLM, but flattening structure is not the same as preserving its semantics.
AI does not make product structure unnecessary. It makes trustworthy structure more valuable, because the more responsibility we hand to agents, the more it matters that they operate on information whose identity, relationships, history, and meaning are known. That does not automatically mean everything belongs in one bigger database. That distinction is the one I want to explore.
Enterprise product data is the dark matter of AI
Stonebraker’s second point concerns enterprise information itself. Foundation models were trained on public data. Enterprise data is different: private, behind permissions, with schemas that evolved over decades, inconsistent names, overlapping semantics, and derived data with dependencies and provenance. He calls the accumulated degradation inside long-lived enterprise databases “schema rot.” Frontier models have never seen this information and cannot know it simply by getting smarter. It is the dark matter of AI.
Engineering and manufacturing may be the best example. Take a simple question: can we use this motor in the new product configuration? Where is the answer? Probably nowhere. The spec is in a PDF. The latest revision is in PLM. The assembly structure is in a BOM. Electrical requirements are in another system. Qualification tests live somewhere else. The supplier situation is in ERP. Someone documented an exception in an ECO. And six months ago an engineer explained the real design decision in an email or a meeting.
The answer is not retrieved. It is constructed from context. That distinction, between data and context, is the center of this article.
Agents need product context, not just product data
Traditional PLM was built to manage product data. Data can tell me this is Part PN-123, revision C, in Assembly 456, supplied by ABC at $12.40. Context answers different questions. Why was revision C created? Which requirement triggered it? Which configurations are affected? Was the supplier swap temporary or permanent? Which test established that the change is acceptable? What alternatives were rejected and why? Who approved it? Which manufacturing, sourcing, quality, and service decisions depend on it?
The database stays essential because much of this is structured. But the database alone does not produce context. Context is assembled from data plus relationships, history, provenance, configuration, documents, decisions, rules, and communication.
This is where all three visions show their limits. The AI-native vision confuses information with text. The large-platform vision confuses context with centralization. The traditional PLM argument confuses the theoretical capability of a data model with an architecture companies can actually implement and sustain across the lifecycle.
So the interesting question is not “database or AI?” and it is not “how big should the PLM database become?” It is: what product information must remain structured and authoritative, and how do we continuously assemble that distributed information into trustworthy context for humans and agents? That distinction between data, authority, and context is where the architecture of future PLM begins.
Product context does not require one database
For decades the reflex of enterprise software was to expand ownership. If product information lives outside PLM, bring it in. If a process runs in spreadsheets, rebuild it in PLM. If another application holds product data, synchronize it. If the lifecycle is fragmented, grow the platform. There is logic in that; a common system creates consistency. But companies run CAD, PDM, PLM, ERP, MES, ALM, requirements tools, supplier portals, quality systems, service platforms, databases, spreadsheets, and dozens of specialized engineering tools. These systems (and silos) exist for reasons, and AI is not going to make them disappear. Yet “demolish silos” was for a very long time one of the strongest messages in PLM sales. Organizational silos are real, and they will continue to exist.
So the question is not which single system should own everything. It is: which system is authoritative for each piece of information, and how do we connect those authoritative sources into persistent product context? That is a different architectural problem.
The Product Graph is a model, not a graph database
Product information naturally forms a graph. A part belongs to an assembly, a CAD model represents a part, a requirement is satisfied by a design, a test verifies a requirement, a change affects an item, a supplier provides a component, a failure occurs on a serial number, a decision explains a change. I think about product information as a Product Graph and find it useful.
Stonebraker, though, is skeptical of graph databases. He argues most graphs can be represented as node and edge tables and questions whether native graph engines earn their keep for typical workloads. Agree or disagree on performance, the architectural lesson stands: a Product Graph is not a graph database. The graph is the logical model. The database is an implementation choice. Some information lives in relational tables, some relationships may be served by a graph engine, documents stay in object storage, search indexes and vector stores support retrieval, event stores capture history, and specialized applications keep owning their domains. The goal is not to pick a database winner. It is to select a combination of databases that preserves identity, structure, relationships, provenance, configuration, and history, and to assemble them into the context a specific question or action needs.
Reading is forgiving. Acting is not.
This matters most when AI moves from copilot to agent. Today’s demos are mostly reading: find information, summarize documents, explain this BOM, compare two revisions, flag missing properties. Reading is forgiving. Now imagine asking an agent to release this revision, update the manufacturing BOM, sync approved data to ERP, create an RFQ for the new parts, and notify the supplier.
What happens if the PLM release succeeds and the ERP sync fails? If the RFQ goes out and the BOM change is later reversed? If another engineer edits the same item mid-workflow? What permissions does the agent hold, who authorized the action, what exactly changed, can we audit it, can we recover?
Stonebraker’s DBOS work returns to ideas the database field spent decades developing: durable state, transactions, atomic operations, compensating actions, and sagas that logically reverse completed steps when a long-running workflow cannot finish. Suddenly databases do not look obsolete at all. The more agents act on engineering and manufacturing data, the more persistence, transactions, permissions, provenance, and auditability matter. The future is not LLM plus documents. It is LLM plus structured data plus context plus governed state plus durable workflows.
Distributed authority, connected context, governed action
So I don’t believe in a database-free AI environment; structure matters too much. I don’t believe the answer is one larger platform database absorbing the whole lifecycle. And I don’t believe existing PLM architectures can be declared sufficient because their data models theoretically cover most needs.
The architecture I see emerging has three layers.
Systems of authority. CAD owns design. PLM may own structure, revisions, and change. ERP owns commercial and production data. ALM owns software. Requirements tools own requirements. MES owns execution. Quality and service own theirs. The principle is not that everything moves into one database. It is that the authority of every piece of information is known.
Product context. Above and across those systems sits a persistent way to connect identity, relationships, configuration, provenance, history, decisions, semantics, and dependencies. This is not a search, and it is not a federation. It is the persistent connected context of the product.
Human and agentic action. Humans and agents operate against that context: ask questions, reconcile inconsistencies, evaluate change impact, identify risk, source components, prepare changes, and eventually execute transactions across multiple authoritative systems.
Distributed authority. Connected context. Governed action.
Maybe the PLM database was never the product
This leads to an uncomfortable question for the PLM industry. For decades vendors differentiated on data models: how Items are represented, how BOMs are stored, how documents connect, how configurations and revisions are modeled. Those questions still matter. But AI is moving the center of gravity. The question is less “what records do you have?” and more “what context can you assemble around the problem I am trying to solve?” and, eventually, “what action can you safely take with it?”
The database does not disappear. It becomes infrastructure. And infrastructure can become less visible and more important at the same time.
So, does the PLM database have a future?
Absolutely, and perhaps a bigger one than before. AI does not eliminate the need for structured information, identity, relationships, permissions, provenance, transactions, or persistent state. It raises their importance. What is reaching the end of its useful life is the assumption that the future of product information architecture is determined by how much we can pull into the PLM database.
For forty years the central question was where to store the product data. AI asks a different one: how do we assemble trustworthy product context for a human or an agent about to make a decision or take an action? Databases remain part of the answer, but the database is no longer the architecture. The architecture connects multiple systems of authority into persistent Product Context. And as that context comes to capture not only what the product is but how it evolved, why decisions were made, what was tried, what failed, and what happened across organizations and lifecycle stages, it becomes Product Memory..
That is where I think the next generation of PLM is going. This article is the first in a series in which I will lay out that vision as a counterpoint to the FPHE platform model. The next piece will take on the hardest part: what governed action across multiple systems of authority actually requires.
Best, Oleg
Disclaimer: I’m the co-founder and CEO of OpenBOM, an AI-powered PDM and PLM platform for engineering and manufacturing teams. My opinion can be unintentionally biased.
