If I Got a Dollar for Every Time I Heard ‘Why Doesn’t This Work on My Machine’
Adding a Data Snapshot to Your Mendix Model.
Estimated reading time: 4 minutes
Let’s start with a small confession…
If you’ve been working in Mendix for a while, chances are there are still a few features quietly sitting in the corner that you know exist… but haven’t really touched yet.
For me, one of those features was working with a data snapshot of my local model. But not anymore!
In this blog, I’ll walk you through what it actually is, why it’s more useful than it might seem at first glance, and how you can start using it yourself, so you don’t keep sleeping on this surprisingly handy feature.
It’s not flashy. It’s not something you reach for every single day. But once you do start using it… you’ll probably find yourself wondering: “Where has this been all my life?”.
Why This Matters More Than You Think
When you run your Mendix app locally, you’re working with a built-in database that lives entirely on your machine. It’s fast, convenient, and perfect for development, but also, a little bit… lonely. Your carefully crafted test records, your perfectly configured reference data, that one setup you finally got right after 20 minutes of trial and error, unfortunately none of it automatically exists for your teammates. And that’s where things tend to get messy.
The Moment It Starts Hurting
This usually becomes noticeable in two very specific situations:
- Early project phases
In the beginning of a project, there might not be a shared environment available yet. No acceptance node, no consistent deployment pipeline, just developers running things locally.
That means:
- Everyone is creating their own data
- Everyone is configuring things slightly differently
- And nobody is quite sure what the “correct” setup looks like
This is exactly where snapshots shine. You can establish a shared baseline before infrastructure catches up with you.
- Configuration-heavy applications
You know the type of project:
- Master data tables
- Lots of configurable settings
- Feature toggles
- Reference entities
One developer spends time setting everything up properly, tests the feature, and moves on. Then another developer pulls the latest version and… “Why doesn’t this work?” “Oh… I think you need to configure like 12 things first.” Not ideal.
With a data snapshot, that carefully prepared configuration can be captured once and reused by everyone. No unnecessary time spent answering questions that could have been prevented, more time to build awesome functionality.
So What Is a Data Snapshot in Mendix?
In simple terms, a data snapshot is a saved state of your development database at a specific moment in time. Mendix actually allows you to commit your local development database to version control, making it available to other developers working on the same app.
When someone else pulls that snapshot, their local database is updated to match yours, data included.
Step-by-Step: Sharing a Data Snapshot in Mendix Studio Pro
Alright, let’s get our hands a little dirty. Let’s walk through it together.
Step 1: Set the Stage
Remember: this snapshot becomes everyone’s starting point. Before you hit any “commit” buttons, take a quick look at your app.
What you want here is a clean, intentional dataset:
- Useful test records
- Necessary reference/configuration data
- No weird leftovers from debugging
Step 2: Add the snapshot
Now for the main event.
- Go to Version Control → Add snapshot of data
- Confirm the commit
And that’s it, you’ve just turned your local database into a shareable snapshot.
Behind the scenes, Mendix takes your built-in database (the HSQLDB running locally) and stores it alongside your project in version control, so other developers can use it too. It should also work with different database management systems, but personally I haven’t tested this yet.
Step 3: Commit Your App
Commit you app to push the version with the data snapshot to the team server.
- Go to Version Control → Commit
- Commit your changes
Step 4: Your Teammates Pull the Magic
Now comes the “oh wow, that was easy” moment for your teammates. They just have to pull the commit where the snapshot was included. Their local database is now replaced with your snapshot. Just: pull, run, done.
There’s one small thing to be aware of:
- If your teammate’s local database is empty, everything works right away.
- If they already have data in their local database, things can be a bit less automatic.
In that case, they may need to manually copy the contents of the data-snapshot.zip file > data directory into the Deployment > data directory of their model repository.
It’s a small extra step, but once you know it’s there, it’s easy to handle—and it saves you from wondering why your perfectly crafted dataset didn’t magically appear.
Bringing It All Together
At its core, this isn’t just about a feature hidden in a menu somewhere. It’s about removing friction. It’s about turning this:
“It works on my machine… did you create the three reference records? And toggle that one thing?”
Into this:
“Just pull and run, you’re good.”
And especially in those early project days, or in apps full of configuration, that small shift makes a big difference.
Happy developing!
Chelsea, over-and-out
Ready to make local development a little less painful?
The next time you find yourself explaining why something only works on your machine, consider creating a data snapshot instead. It takes just a few minutes, saves your teammates valuable time, and helps keep everyone working from the same starting point.
If you have any questions or comments? Feel free to share them with us!
A Few Tips from “Flip” a.k.a. Chelsea
Let’s save you (and your teammates) some minor frustrations:
- Treat Snapshots Like a Shared Space
You’re not just working for yourself here.
Before committing:
- Remove junk data
- Keep things minimal but complete
- Avoid anything sensitive
- Don’t Overdo It
Yes, it’s easy to commit a snapshot.
No, you don’t need to do it every hour.
Good moments to create one:
- After setting up baseline configuration
- Before handing over a feature
- When onboarding someone new
- Communicate Before Overwriting
Committing another snapshot replaces the original data. A quick heads-up goes a long way.
