<img height="1" width="1" style="display:none;" alt="" src="https://px.ads.linkedin.com/collect/?pid=1195114&amp;fmt=gif">

Top 10 performance improvement tips for Mendix

Bart Tolen
Bart Tolen


As promised a few blogs ago, I have written this blog with my top 10 performance improvement tips for Mendix. This blog is technical in nature and assumes knowledge of the Mendix modeler and some infrastructure knowledge, like what a database index does or how web server compression would help.

This top 10 is of the top of my head and based on experience. Without further introduction I present to you my list:


Yes, really create indexes. As soon as an entity (a table or more tables in the case of inheritance) contains a substantial amount of data you will notice a performance degradation. Find out what searches are done. Check the model for xpaths that use attributes. Also check your search forms with grids.


They execute every time a record is loaded. And many times if the calculated attribute is used in a grid.

If you do use them, make them read-only aka without side-effects and make them fast!


A grid loads chunks, so a smaller chuck size can improve performance.

Think about what data the client needs. With permissions or model design you can make sure a minimal set of attributes is sent to the client. This also applies to the complexity of the form in the modeler.

Drop-down references can take a really long time to load. Both because of the data volume and also the client-side JavaScript engine time building up the menu.

Archive data if you can.


The iterations of loops in loops are executed many times and a lot of small pieces make a slow puzzle.

If you cannot avoid loops in loops, try to minimize the amount if iterations, try to do work outside the loops where possible, try using in memory lists instead of retrieves.


This prevents locking a record and having other concurrent users wait.

Scheduled events or batch jobs should work in small batches/chunks. Otherwise they lock data for a long period of time.


Mendix manages separate tables for each inherited entity. Mendix has separate security for inherited entities, so especially be cautious with xpath constraints on entities with inheritance and a lot of data. I’ve seen the generated SQL statements go from half a page to 30 pages (A4) and the corresponding response time from below 2 seconds to above 30 seconds.


Mendix optimizes a database retrieve followed by an aggregate (count) if the list resulting from the database retrieve is not used elsewhere. So sometimes it might help to retrieve twice, because the first retrieve is optimized and the second is only executed in certain business cases


Mendix preloads data of references sets even if the data is not needed. So a reference set with a lot of references in it gets loaded every time the entity is loaded in for example a microflow.

Also minimize the use of the both option on reference sets. This creates the problem on 2 sides and this option is hardly ever needed.


For those on premise installations a web server that serves static content and compresses all communication really helps a lot.

For those in the Mendix cloud: you’re lucky. Mendix has already arranged this for you.


Trivial, but still often an option on the server side. Add ‘AppEngines’ in the Mendix cloud or extra virtual capacity in your data center.

Mendix is based on a JavaScript framework and an older browser can be really slow. So use the best browser you can. In the past we had Google frame under IE6 or IE7. Those days are gone I hope.


I hope my list helps you create faster applications. If you would like to debate about the contents or if you are in desperate need of assistance with your performance challenges, feel free to drop me an email.

The Mansystems Application Performance Management (APM) Suite of tools can greatly assist you in pinpointing performance issues, even before they arrive via complaints of end users. I have written more about the application of this suite of tools in blog ‘just-in-time performance management’. 

Bart Tolen

Bart Tolen

Bart Tolen has a master of engineering in applied physics and has worked with Mendix since 2010. He is a Mendix MVP, Solution Architect, and specialized in performance. Bart is the thought leader and designer of Mendix APD.

Related posts

Cloud architecture patterns

How to offload work from Mendix to Azure? As someone who has been working with Mendix for several years I am acutely aware of the limitations of the ...

Read More

Best practices for writing custom actions in Mendix

Since actions are the main way of using many app store modules, it is worth investing some time and thought in designing good actions. Here are ...

Read More

Best practice for adding a java dependency to Mendix

My journey with Mendix started more than four years ago. Due to the nature of my Mendix projects many times I had to use third-party java libraries ...

Read More