Dolt vs MySQL for FiveM: Why Branching Databases Change Everything
MySQL works for FiveM until it doesn't — one bad migration, one corrupted economy, and you're restoring from a backup that's 6 hours stale. Dolt gives you git-style branching for your database.
Every FiveM developer has the same MySQL horror story. You push a schema change to production, something goes wrong, and now you're restoring from a backup that doesn't include the last 6 hours of player data. Or worse — you don't have a recent backup at all.
MySQL is the default database for FiveM because oxmysql and ghmattimysql were built for it. But "default" doesn't mean "best." There's a database that speaks the MySQL wire protocol, runs every query your existing scripts already use, and adds one feature that changes everything: branching.
What Dolt Actually Is
Dolt is a SQL database that implements git-style version control at the data level. Every write is tracked. You can branch, diff, merge, and revert your entire database the same way you branch and merge code.
It's not a wrapper around MySQL. It's a ground-up implementation of the MySQL protocol with version control built into the storage engine. Your existing FiveM scripts connect to it exactly like they connect to MySQL — same connection string format, same query syntax, same oxmysql configuration.
The difference is what happens after those queries run.
Branching for Development
Here's the workflow that Dolt enables:
You have a main branch that your live server runs against. When you're developing a new feature — say, a property system that adds new tables and modifies the player data schema — you create a branch.
CALL DOLT_BRANCH('feature/property-system');
CALL DOLT_CHECKOUT('feature/property-system');Now you develop against that branch. Add tables, modify columns, insert test data, break things. Your live server on main is completely unaffected. When the feature is ready, you merge.
CALL DOLT_CHECKOUT('main');
CALL DOLT_MERGE('feature/property-system');If the merge introduces problems, you revert. Not "restore from backup" — a clean, instant revert to the previous commit.
CALL DOLT_REVERT('HEAD');This is the workflow every software team uses for code. Dolt brings it to data.
Schema Diffs That Save Hours
One of the most underappreciated features: dolt diff shows you exactly what changed between two points in time, at both the schema and data level.
SELECT * FROM DOLT_DIFF('main', 'feature/property-system', 'players');This returns every row that was added, modified, or deleted in the players table between those two branches. For debugging economy issues — "who got $10 million out of nowhere" — this is invaluable. Instead of grepping through server logs, you query the diff directly.
Schema diffs are equally useful. Before merging a feature branch, you can see exactly which tables were added, which columns changed, and what the migration looks like — without writing a migration file.
Rollbacks That Actually Work
MySQL backups are point-in-time snapshots. If your backup runs at 4 AM and something breaks at 10 AM, you lose 6 hours of data. With Dolt, every transaction is committed to the version history. You can roll back to any point — not just the last backup.
For FiveM servers, this means:
Economy exploits get unwound cleanly. Find the commit where the exploit happened, revert to the commit before it, and the economy is restored without affecting legitimate transactions that happened before the exploit.
Bad migrations are instantly reversible. No scrambling to find the right backup file, no downtime while you restore, no lost data.
Audit trails are built in. Every change to every row is tracked with timestamps and commit metadata. When a player disputes a transaction, you can show them exactly what happened and when.
Performance Considerations
Dolt's query performance has improved dramatically over the past two years, but it's still roughly 2-3x slower than MySQL for raw query throughput on equivalent hardware. For most FiveM servers — which are not high-throughput database applications — this difference is imperceptible.
If your server handles 64-128 players and your scripts make standard oxmysql calls, Dolt runs those queries without any noticeable latency difference. The bottleneck in FiveM is almost never database query speed. It's script execution, network latency, and entity synchronization.
Where you might feel the difference: bulk operations like importing large datasets or running analytics queries across hundreds of thousands of rows. For those cases, you can run a MySQL read replica alongside Dolt for reporting purposes.
Migration Path
Switching from MySQL to Dolt doesn't require rewriting anything. Export your MySQL database with mysqldump, import it into Dolt with dolt sql, update your connection string, and restart your server. Your oxmysql or ghmattimysql config changes one line — the host and port.
Start by running Dolt on your development server first. Get comfortable with the branching workflow. Once you trust it, migrate production. The fallback is always there — Dolt exports to standard MySQL format, so you can switch back if needed.
Waifu N Weebs uses Dolt in our development workflow and recommends it for any serious FiveM server. Talk to us about migrating your server's database infrastructure.
Need a dev who builds servers like this?
Get a Quote