After working on MES projects across multiple plants, I’ve noticed a pattern. Sooner or later, someone looks at the MES database and decides it should become the answer to every data problem in the plant. What starts as a system for managing production orders, genealogy, and execution gradually turns into a repository for raw Level 2 tags, years of sensor history, lab results, reports, analytics, and every piece of data that nobody wants to throw away.
At some point, the MES quietly stops being treated like an execution system and starts being treated like a historian, a reporting warehouse, and a data lake all at once. This usually sounds perfectly reasonable in meetings. “Why send data elsewhere if MES already has a database?” And that’s often where the trouble starts.
MES is not your company’s basement
Using MES as your long-term storage layer is a bit like using your kitchen counter as your warehouse. Can you do it? Technically, yes. Will things function for a while? Probably. But eventually, you run out of space, things get slower, nobody can find what they actually need, and the place designed for execution becomes cluttered with storage problems it was never built to handle.
MES exists to run production. It should answer questions like: What should this piece do next? Can this order be processed? What is the material status right now? Did this production step happen correctly? What decision needs to happen in the next few seconds? Those are fundamentally different from questions like: What was furnace zone 4 temperature every second for the last 5 years? Can we train a predictive maintenance model on all vibration signals? Can corporate analytics combine this with ERP, quality, and energy data? Both categories matter, but they are different problems, and they usually require different systems.
MES vs Historian vs Data Lake: They are not interchangeable
A practical way to think about it:
- MES = Air traffic control: it manages active movement, immediate decisions, sequencing, and operational coordination.
- Historian = Flight recorder: it stores high-frequency time-series data efficiently for operational analysis and troubleshooting.
- Data Lake = Aviation archive + analytics lab: it stores massive amounts of structured and unstructured data for long-term analysis, machine learning, enterprise reporting, and cross-system integration.
Historians were built specifically for this problem. Storing millions or billions of rapidly changing values efficiently is what they do. Asking MES to perform the same role is a bit like using a forklift to move coils and then deciding it should also haul material across the country. Both move things, but only one was designed for that job.
When these roles get blurred, architecture starts degrading. MES should excel at production workflows, genealogy, dispatching, transactional state, and operator actions. Historian should handle PLC tags, continuous process variables, and trend analysis. Data lakes should support multi-year benchmarking, AI, data science, regulatory archives, and combining MES with ERP, LIMS, and maintenance data. The problem is that I’ve repeatedly seen MES databases treated like all three.
“Storage Is Cheap” Until Architecture Isn’t
One of the most common defenses of this approach is “storage is cheap.” And while disk space itself may be relatively inexpensive, architecture absolutely is not. In one project, a genealogy screen that operators used dozens of times per shift started taking noticeably longer to load. Nobody had changed the workflow. Nobody had added new business logic. The root cause was simply that years of historical process data had accumulated in tables that were never designed for that volume. What began as a convenient place to store extra information eventually became a performance problem everyone had to live with.
The MES becomes heavier not because production became more sophisticated, but because nobody respected system boundaries. The worst part is that this rarely happens through one catastrophic design mistake. It usually happens gradually, one extra integration, one temporary archive, one custom table at a time, until years later the MES database feels less like a production system and more like a garage filled with things nobody wanted to throw away.
Why This Decision Looks Smart at First
This architectural mistake rarely starts because someone is careless. It usually starts because someone is trying to save money. Why buy another system? Why maintain another database? Why build another integration?
On paper, putting everything into MES feels efficient. Fewer systems. Fewer moving parts. Lower costs.
The problem is that complexity doesn’t disappear. It just moves. Instead of paying for proper architecture upfront, you end up paying for slower performance, harder upgrades, and increasingly fragile integrations later.
When Technical Debt Becomes Operational Debt
The long-term maintainability costs are often even worse than the performance problems. When MES becomes the central storage point for everything, every schema change becomes political because operations, reporting, integrations, and dashboards all depend on the same structures. Every upgrade becomes harder because years of historical and analytical customizations pile on top of execution logic. Troubleshooting becomes messier because separating operational truth from historical bulk gets increasingly difficult.
New plant rollouts also become slower because the MES template now carries years of unnecessary architectural baggage. I’ve seen temporary reporting tables become so embedded in core operations that nobody wanted to remove them because too many downstream reports depended on them. This is where technical debt quietly transforms into operational debt, and where systems originally designed to improve production start becoming harder to change than the process itself.
Clear Boundaries Build Better Architecture
A healthier approach is not to make MES smaller, but to make its role clearer. MES absolutely should produce valuable data, but producing data is not the same thing as becoming the permanent home for all data. In a more sustainable architecture, Level 2 and PLCs feed historians for raw operational detail, MES manages execution, transactions, context, and genealogy, and enterprise platforms like data lakes or warehouses aggregate MES, historian, ERP, and LIMS data for broader strategic use.
So what does a healthier architecture actually look like? Not one where MES does less, but one where every system does what it was designed to do.
MES should decide what matters operationally. Historian should preserve what changes rapidly. Data lakes should aggregate what matters strategically. That separation can feel like extra complexity upfront, especially when companies are trying to minimize systems, infrastructure, or licensing. But in real projects, it usually creates far less pain over time.
Good Architecture Starts With Clear Roles
“The goal isn’t to make MES do more. It’s to make sure MES keeps doing the right things well.”
I understand why this architectural mistake happens. MES is already there. It already has data. It feels easier than designing broader architecture. But “already there” is not the same as “designed for it.” A good MES is like a plant floor manager: focused on what needs to happen now. Once you ask it to also become historian, enterprise archive, and analytics platform, you are essentially asking your shift supervisor to also run accounting, legal, and corporate strategy. Eventually, something important gets neglected. MES is critical, but not everything belongs there. Sometimes better architecture is less about adding more systems, and more about respecting what each system is actually supposed to do.
One of the simplest ways to avoid turning MES into a data lake is to ask a basic question whenever new data needs to be stored: which system is actually responsible for this information? Not all production data has the same purpose. Some data is needed to run production in real time, some is needed for operational analysis, and some is only valuable when combined with information from across the enterprise. The table below shows where a few common examples typically belong.
| Data Type | System |
|---|---|
| Production Order | MES |
| Material Genealogy | MES |
| Current Material Status | MES |
| Operator Actions | MES |
| Furnace Temperature Every Second | Historian |
| PLC Tags | Historian |
| Vibration Signals | Historian |
| Process Trends | Historian |
| Corporate KPI Dashboard | Data Lake |
| Multi-Plant Benchmarking | Data Lake |
| Machine Learning Dataset | Data Lake |
| Combined MES + ERP + LIMS Analytics | Data Lake |
The goal isn’t to make MES do more. It’s to make sure MES keeps doing the right things well. When MES runs production, historians preserve operational detail, and data lakes support enterprise analytics, everybody wins. When MES tries to be all three, eventually nobody does.