MATLAB vs Python: Future-Proofing Industrial R&D

Today’s industrial R&D engineers are drowning in data. An hour of engine testing can generate terabytes of sensor data across thousands of channels at 10kHz+ frequencies. Previously, engineers might have dumped this data into storage and used tools like MATLAB to process it in batches. Now that digital twins are becoming mainstream, more R&D engineers are opting to run simulation models on their data in real time. 

The problem is that MATLAB isn’t entirely suited to real-time processing. It can be done, but it’s painful. Both technically and financially. When our founders worked at McLaren, they moved most of their data pipeline from MATLAB to Python, which was cheaper and easier for everyone to learn. You should do the same. Why? In the long run, it will help you develop better products at a faster rate and at a fraction of the cost. 

Before we get into it, let us be clear: we have absolutely nothing against MATLAB. It’s just not a great fit for modern Industry 4.0 use cases that require real-time data processing. MATLAB is still a tremendously powerful tool! Let’s first look at how it became the de facto tool for scientific computing. 

Why MATLAB Is So Popular

MATLAB (short for MATrix LABoratory) was created in the late 1970s by Cleve Moler, a professor of mathematics, as a tool for his students to easily use LINPACK and EISPACK, libraries for numerical linear algebra without requiring knowledge of Fortran. MATLAB became a commercial software application in 1984. 

Over time, MATLAB expanded beyond linear algebra to include toolboxes for signal processing, control systems, and many other domains. In the 1990s, it added Simulink, a graphical modeling tool for system simulation, making it popular in engineering and applied sciences. Today, MATLAB is widely used in fields like robotics and machine learning. 

Engineers and scientists love its integrated development environment, which provides a unified platform for coding, testing, and analyzing data. MathWorks also provides excellent support, documentation, and training, and they offer a library of toolboxes tailored to specific industries.

The problem is that none of this comes cheap. In fact, it can be wildly expensive.

How Much Is Innovation Worth?

For the sake of simplicity, suppose that you have a small team of 10 industrial R&D engineers using MATLAB licensed annually. It’s about $8,600 per year for the team. After three years, it’s $25,800. And that’s without Simulink, one of their most popular products. 

Simulink costs about $1,330 on an annual license; after three years of using MATLAB and Simulink, you would have spent about $65,700. Then, there’s the toolboxes. We won't get into detail about these, but if you include a few of them, you can easily spend about $100,000 over 3 years.

If you want to run MATLAB or Simulink as automated processes on a server, you’ll need yet another license. And managing these server licenses is an utter pain, especially when trying to use MATLAB in the cloud. Just check out this license error cheat sheet as an example of what users often encounter. If you want to run MATLAB in ‌a virtualized environment (like Docker), your engineers will likely spend many, many hours troubleshooting these kinds of errors.

Is this all worth the hassle and complexity? Well, no. Especially considering that many IDEs that support Python are also completely free (such as Visual Studio Code and PyCharm Community Edition). Stand-alone processes can be run and deployed in the cloud with free open-source tools. 

Industrial R&D has its own unique complexities, such as incorporating hardware and running advanced mathematical algorithms. However, one could argue that MATLAB does not scale well to the requirements of Industry 4.0, so it’s no longer worth the hefty price tag and operational cost of running it.

Digital Twins Need Real-Time Data Processing—Which MATLAB Wasn’t Built For

More R&D teams are embracing the concept of the digital twin, which needs real-time data by design. For the uninitiated, a digital twin is a dynamic, virtual replica of a physical asset, system, or process (like a car’s engine or a machine on a production line). It updates in real-time using data from its physical counterpart. Unlike static simulation models, digital twins let you simulate, monitor, and optimize performance on the fly.

This makes digital twins a fantastic R&D tool because you can use real-time data to simulate various "what if" scenarios. You can test new ideas and explore different options without disturbing the actual physical asset or process.

The challenge is you need a certain kind of infrastructure to get this running properly, which can be a hassle if you rely too much on MATLAB. To illustrate this, let’s look at an example from an academic paper titled “Automated and Systematic Digital Twins Testing for Industrial Processes” (most companies don’t share the details of their internal R&D pipelines, so this is the next best option). 

The paper describes a digital twin (DT) that simulates the complex process of induction heating of steel bars in a forging factory. It models the dynamic behavior of the heating furnace and the steel bars, the control systems used to manage the process, and the sensor data that monitors it. The goal is to help optimize and automate the production line by using real-time data. 

Let’s skip the technical details, but the example helps us understand how the components of a DT architecture are deployed. They used a Deep Reinforcement Learning (DRL) Model as part of a control mechanism that learns to optimize the production process by interacting with the Digital Twin environment.

The following diagram is our reinterpretation of their architecture. We've revised it because the Python library they originally used for stream processing, Faust, is no longer maintained by its original creator, Robinhood.

So, we've replaced Faust with Quix. All the other components remain the same. The OPC-UA server sends factory data to a ThingsBoard IoT gateway that converts the OPC-UA data to MQTT and sends it on to an MQTT broker. Quix Streams (running in Quix Cloud) use an MQTT connector to read the messages, collect the data, and turn it into metrics. It creates regular snapshots of the processed data and compares it with the data being simulated by the digital twin. The simulation in the digital twin can then be updated in response to the "real-life" factory data.

You could also run MATLAB in containers to process the data,, but you’d quickly hit a major obstacle.

Running MATLAB in Docker Is Painful and Expensive

We have dealt with many teams who have trouble running MATLAB in Docker—for example, a digitalization team at a renewable energy company that had this specific issue. They ‌wanted to simulate chemical processes within reactors using a digital twin. It was costing them too much to run MATLAB applications in the cloud, so they wanted to switch to Python. This is because MATLAB containers are far larger than Python containers, require more resources, and are more expensive to run on platforms like AWS. 

Migrating to Python enables the team to work with smaller, more efficient containers with fewer resources, lowering their cloud computing expenses. It also helps them avoid the technical hassle of validating MATLAB licenses from within containers. There are other operational wins, too. Python is more streamlined and generally works better with containerization. This lets them work faster and makes it easier to deploy and manage their applications.

Note that the team isn’t abandoning MATLAB completely, as they want to reuse some of their existing MATLAB functions. They intend to build processing services that apply these functions to sensor data streams. The goal is to extract ‌valuable algorithms from MATLAB and deploy them as Python applications.

The Business Case for Technical Standardization

Chances are, Python is used often in other parts of your organization. If Industry 4.0 is about connecting and consolidating data, you want most of your tools to speak the same language. 

Take the company mentioned in the previous section: they already use Python for much of their API and back-end development. By incorporating more of their analytical and modeling components into Python, they hope to reduce ‌friction in their wider development pipeline. 

The goal is to standardize their tools and improve the developer experience overall. They also want to incorporate real-time data into their web platform. Python can easily handle real-time data processing and has good libraries (such as Quix Streams) for building the necessary tools.

The shift from MATLAB to Python seems to be part of the company's broader direction to standardize their tech stack around Python. This initiative will make it easier to manage and maintain the company’s software infrastructure and allow for a more cohesive development environment. As the company grows, it needs a technology stack that will scale easily and cost-effectively. Python-based applications are highly scalable and easily deployed on any cloud platform.

Migrating to Python is a Sound Strategic Bet

Let's be honest - migrating from MATLAB to Python isn't a small undertaking. Your team will need time to learn new tools and port existing code. There will be grumbling. There will be growing pains. But here's the thing: this transition is inevitable for most industrial R&D teams, and the longer you wait, the more technical debt you'll accumulate.

The writing is on the wall. Python is becoming the de facto standard for real-time data processing, machine learning, and digital twin development. It's more cost-effective, has a larger talent pool, and integrates better with modern cloud infrastructure. While MATLAB remains an excellent tool for certain specialized tasks, it wasn't designed for the real-time, cloud-native requirements of Industry 4.0.

The good news is that you don't have to make the switch overnight. MATLAB has great interoperability with Python so you can use both together as a bridging strategy. Start small - perhaps with a new project or a specific component that would benefit from real-time processing. Use this as an opportunity to build expertise and confidence in Python within your team. Over time, you can gradually migrate more components while keeping your critical MATLAB functions running where they make sense.

Remember, this isn't just about saving money on licenses or finding cheaper talent. It's about future-proofing your R&D capabilities. As digital twins and real-time processing become more central to industrial innovation, you'll want a technology stack to keep up. Python isn't just a cost-cutting measure - it's a strategic investment in your organization's ability to innovate and compete in the age of Industry 4.0.

Make no mistake; even industrial R&D is gradually pivoting towards Python and away from proprietary frameworks. The teams who do it early will come out on top. The laggards will find out the hard way that it’s always harder to modernize your infrastructure when you’ve left it to the last minute.