Yes, you can sometimes build AI models directly on an MES database without a data warehouse. For limited, read-only, non-critical analysis, it may be technically possible.
But as a general production approach, it is usually not the right default in regulated manufacturing environments.
The issue is not whether it is possible. The issue is whether the MES database is the right place to source, govern, contextualize, validate, and retain the data needed for reliable models without creating operational or compliance risk.
MES databases are optimized for execution, not analytics. Query patterns for model training and feature generation can compete with shop floor transactions, reporting jobs, and integrations. In brownfield plants, that can create performance instability at exactly the wrong time.
Raw MES data is rarely analytics-ready. It often contains missing context, inconsistent timestamps, event duplication, late-arriving records, code-value variations, and plant-specific workarounds. If the data model reflects years of operational exceptions, the model will learn those inconsistencies too.
You usually need data beyond MES. Useful manufacturing AI often depends on ERP, QMS, PLM, historian, maintenance, lab, inspection, and sometimes manual records. MES alone may not contain the full causal chain for quality, throughput, delay, or scrap outcomes.
Traceability and reproducibility become harder. If source records can change after transactions are corrected, backfilled, or reprocessed, you can struggle to prove which data version trained which model. That matters for change control, investigation, and revalidation.
Security and access boundaries get messy. Direct connections from data science tools or AI platforms into a production MES database can expand attack surface, increase privilege complexity, and blur IT and OT responsibilities.
Validation effort rises. In regulated settings, the more tightly the model depends on live transactional structures and brittle custom joins, the harder it is to validate behavior and manage changes safely.
It can be reasonable if all of the following are true:
You are using a read replica, reporting replica, or export, not the primary production database.
The use case is narrow, such as exploratory analysis, anomaly screening, or a pilot on one line or process area.
The data needed is mostly contained in MES and does not require heavy cross-system reconciliation.
You have stable identifiers, timestamps, revision handling, and event semantics.
You can document data lineage, model inputs, refresh logic, and change control.
The model is advisory, not making autonomous release, quality, or safety decisions.
Even then, most teams end up creating a curated analytical layer because direct use of MES data becomes hard to maintain as scope grows.
A data warehouse is not the only option. If the concern is cost, time, or architecture overhead, there are middle paths:
Read replicas for isolated analytical workloads
Curated data marts for specific use cases like yield prediction or cycle time variance
Lakehouse patterns if you need lower-cost storage and mixed structured data
Feature stores or governed model input layers if multiple models will reuse the same signals
Historian plus MES plus QMS extracts for process-focused analytics
The practical requirement is not a warehouse by name. It is a governed, query-safe, version-aware data layer that does not put the execution system at risk.
In many plants, the MES is only one piece of a mixed vendor stack with custom interfaces, manual workarounds, and long-lived equipment. That matters because AI projects often fail when teams assume the MES database is a complete and clean system of record. It usually is not.
Full replacement of MES, ERP, PLM, or QMS just to make AI easier is often the wrong move in regulated, long lifecycle environments. Replacement programs can trigger major qualification work, validation cost, downtime risk, interface rewrites, and traceability disruption. A coexistence approach is usually more realistic: extract and govern the data you need while leaving execution systems in place.
If the use case is small, read-only, and non-critical, direct access to a replica of MES data may be acceptable.
If the use case will influence production decisions at scale, combine multiple systems, or need repeatable validation and auditability, build a governed analytical layer first. That can be modest in scope, but it should exist.
So the short answer is yes, but usually not directly against the live MES database, and usually not without some intermediate data architecture.
Whether you're managing 1 site or 100, C-981 adapts to your environment and scales with your needs—without the complexity of traditional systems.
