# qcadoo MES: production management for smaller manufacturers > qcadoo MES is a web application for production management, written with PostgreSQL procedures at its core and Java web modules, aimed at small and medium companies rather than large enterprises. The open source edition is the AGPLv3 code in this repository, and it is deliberately narrower than the commercial edition sold by Qcadoo Limited. **qcadoo/mes** — qcadoo MES - friendly web manufacturing software - Repository: https://github.com/qcadoo/mes - Website: https://qcadoo.com/ - Stars: 951 · Forks: 454 - Language: PLpgSQL - License: NOASSERTION - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/qcadoo-mes ## An ERP-shaped tool sized for smaller manufacturers qcadoo MES is described in the README as an Internet application for production management targeted at small and medium companies, combining the functions of large ERP systems while adapting them to what the README calls the specific character of small and medium companies. That framing is the whole product decision, and it cuts both ways. Manufacturing software for a large enterprise is a multi-year deployment with an implementation partner, a dedicated database administrator and a support contract. A tool aimed at smaller companies has to arrive as something one technical person can stand up, with the ERP feature set available rather than negotiated. The topic tags on the repository reinforce the domain: manufacturing, mrp, java and tomcat, with web-application as the delivery model. MRP in the tag list tells you the planning side of the system is the centre of gravity rather than an add-on, and the tomcat tag places the deployment on a familiar Java application server rather than in a container-native stack. The audience, then, is a plant manager or an operations lead at a company of maybe dozens to a few hundred staff who already knows what a bill of materials and a routing are, and who wants production planning, order tracking and inventory in one place instead of in a spreadsheet and a warehouse clipboard. ## PostgreSQL procedures at the core, Java modules around them The repository layout is small and legible, which is unusual and useful for anyone evaluating the system. At the top level there are three entries that matter: `mes-application/`, `mes-plugins/` and a `pom.xml`. The `pom.xml` is the Maven project descriptor, which tells you the build is a standard Java Maven build, and the two directories split the code into the application itself and a plugin layer. A plugin directory in an ERP context usually means business logic can be extended without forking the core, which is the difference between a system that a plant can adapt and one that requires a vendor engagement for every change. The more unusual detail is the primary language. The repository lists PLpgSQL as its primary language, which is the procedural dialect of SQL used inside PostgreSQL. That is a strong statement about the architecture: the business logic sits substantially in the database rather than in Java, in stored procedures and functions that PostgreSQL executes. The practical consequence is that the database is not a passive store here. It is where the rules of the system are written, and that changes what you need to know before touching an installation. Upgrades to schema and procedures are part of the upgrade, migrations carry behaviour as well as structure, and anyone administering the system needs to read SQL procedures as well as Java. It also makes the whole system portable across operating systems, since the platform dependency is the database rather than a native installer. The README itself does not describe the schema, the module boundaries or the plugin interface, so this part of the picture has to be read from the source tree, and the build tutorial linked from the README is the place to start. ## Two editions, and the gap between them The README is explicit that qcadoo MES comes in two versions. The community version is the open source version in this repository. The commercial version is developed and sold by Qcadoo Limited. The listed differences are the ones that matter in an evaluation, and they are not cosmetic: The commercial version provides full support, which on its own changes the risk profile of a production deployment for a company that cannot afford downtime. It offers SaaS deployment, so a plant without a server, or without someone willing to run PostgreSQL and Tomcat, can run it as a hosted service instead of operating it. It includes a REST API for integration. For a manufacturer whose systems are connected to a sales platform, a machine shop or a warehouse system, this is the difference between automated data flow and manual re-entry. It adds ready integration modules with popular ERP software, Pipedrive and SCADA. A SCADA module in particular means production data can flow from equipment to the planning system without a human reading a screen. And it adds features the README names individually: Gantt planning, warehouse material flow, and a maintenance planning module. That list is a good description of what the community edition leaves out, and it should be read that way. Gantt planning and warehouse material flow are core production concerns, not decoration, so a plant whose daily work depends on them is looking at the commercial product. The README does not state whether any of these features exist in the community code in reduced form, and it does not describe the REST API in the community build, so the boundary has to be checked against the source rather than assumed. ## Quick start: a binary release or a build tutorial The README offers exactly two routes, and it points at both without elaborating. The first is to download the latest binary stable release from GitHub Releases, linked as the latest release page. For a plant that just wants to try the system on a test database, that is the shortest path, and it avoids the build entirely. The second is to build qcadoo MES from sources, using a tutorial hosted on Atlassian at qcadoo.atlassian.net under the QCDMESDOC space. That is an external wiki rather than documentation in the repository, so the build instructions, the database setup steps and the configuration details live outside the source tree. The repository itself contains no BUILD file, no Dockerfile and no configuration sample, only `.gitignore`, `LICENSE.txt`, `README.md`, the two module directories and the Maven descriptor. Whatever the tutorial says is the authoritative build path, and you should follow it in order rather than improvising from the `pom.xml`. Two consequences follow for an evaluator. First, nothing in the repository tells you the PostgreSQL version, the Tomcat version or the JDK version the project expects, since those are not recorded there. Second, because the documentation is on a third-party wiki, it is not versioned alongside the code, so a tutorial written for 3.0 may not match a 3.1 checkout. Check the tutorial's revision date against the release you downloaded before you start. There is no entry in the README for an upgrade path from one version to the next, so that is another question for the vendor or for the wiki rather than something to assume. ## Release history, licence and what the AGPLv3 means in practice The licence deserves a careful reading because the two sources in the repository are not phrased the same way. The README states that the code is available under the GNU AGPLv3, and points to `LICENSE.txt`. The licence field on the repository says Other, with a note that GitHub cannot classify it, and also points to the LICENSE file. The file itself is the only authoritative statement, and for a company that may expose the running system to users over a network, the AGPL's network use clause is the part to check with a lawyer, not a summary of it. The release history is short and irregular. Version 3.1.0 was published on 2025-12-05, preceded by 3.0.0 on 2024-12-20 and 2.5.15 on 2024-05-16. The gap between 2.5.15 and 3.0.0 shows a long 2.x line, and the jump to 3.0.0 at the end of 2024 suggests a deliberate break in the major version, which is where breaking changes to the schema or the procedures would live. The last push to the repository was on 2026-10-16, so work has continued after the 3.1.0 release, and the repository is not archived. A gap of several months between a tagged release and the next one is normal for a system of this kind, and it means the code in the default `master` branch may be ahead of the last binary download. The upgrade cost for an adopter is therefore the cost of moving a database forward, not just the cost of swapping a jar. With business rules living in PostgreSQL procedures, a version jump is a migration with behaviour attached, and the README does not document a migration or rollback procedure. That is the concrete first thing to establish with the vendor before scheduling a production upgrade. ## Where qcadoo MES is the wrong tool Three situations rule this project out. First, an enterprise with a formal IT selection process. The commercial edition is sold by Qcadoo Limited with support and a SaaS option, which is the procurement path a larger organisation needs. The community edition in this repository gives you the code and no support, and for a company that cannot afford an outage during MRP recalculation, that is the deciding factor. Second, a plant that needs machine-level integration. The commercial edition is the one that lists SCADA integration modules, and the README does not suggest that the community build exposes a general integration surface. Without a REST API, a shop floor system that cannot be polled and reported on stays a manual operation, however good the planning side is. Third, a team that expects a turnkey product. This is open source code with a README of about twenty lines and the real documentation on a vendor wiki. Nothing is wrong with that arrangement, but it means the evaluation work is on you: reading the schema, reading the plugin interface, and testing the workflows your plant actually runs. The alternative approach, and it is a real one rather than a hypothetical, is to run the commercial edition of the same product instead of the community code. The difference in approach is not a different design but a different boundary: you get the same core system with support, hosting, integration modules and the extra planning modules, and you give up running it yourself and accept the vendor's terms. The other alternative, building on a general purpose ERP and writing the production specifics yourself, costs far more implementation effort but leaves you with a system you control end to end. For most small and medium manufacturers the choice is between the community build with a technical owner in-house and the commercial build with a contract, and the deciding factor is usually integration and support rather than the core MRP functions. ## Conclusion qcadoo MES fits a small or mid-sized manufacturer who wants ERP-shaped production functions without a full enterprise suite, and who is prepared to read the code and the database schema rather than expect a finished product. It is the wrong choice if you need the REST API, Gantt planning, warehouse material flow, maintenance planning or ready-made ERP and SCADA integrations, since the README places all of those in the commercial edition. Before adopting, check two things: whether the AGPLv3 terms in LICENSE.txt suit your distribution model, and whether the features your operation depends on exist in the community code or only in the edition sold by Qcadoo Limited. ## FAQ ### What is qcadoo MES used for? It is an Internet application for production management targeted at small and medium companies, combining functions from large ERP systems with an MRP focus. The repository topics list manufacturing and mrp alongside java, tomcat and web-application. ### How do I install qcadoo MES? The README gives two options: download the latest binary stable release from GitHub Releases, or build from sources using the tutorial on the project wiki. The repository itself contains no Dockerfile or configuration sample. ### What is the difference between the community and commercial versions of qcadoo MES? The community version is the open source code in this repository. The commercial version, sold by Qcadoo Limited, adds full support, SaaS deployment, a REST API, ready integration modules with ERP software, Pipedrive and SCADA, plus features such as Gantt planning, warehouse material flow and maintenance planning. ### What licence is qcadoo MES released under? The README states the code is available under the GNU AGPLv3 and points to LICENSE.txt, while the licence field on the repository is marked as a custom licence that GitHub cannot classify. The LICENSE file is the authoritative statement. ### What technology is qcadoo MES built on? The repository lists PLpgSQL as its primary language, meaning business logic lives largely in PostgreSQL procedures, and the project is organised as a Maven build with mes-application and mes-plugins modules. The topic tags include java and tomcat. ## Sources - [Issues](https://github.com/qcadoo/mes/issues) - [Project website](https://qcadoo.com/) - [qcadoo/mes on GitHub](https://github.com/qcadoo/mes) - [README](https://github.com/qcadoo/mes/blob/master/README.md) - [Releases](https://github.com/qcadoo/mes/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/qcadoo-mes