There are plenty of reasons to use Dolt as your database. Dolt is the world’s first and only version-controlled SQL database. Dolt allows you to track changes to database tables just like Git allows you to track changes to files, all at database-level performance.
Traditionally, video game companies found Dolt useful for managing game configuration. Machine learning teams used Dolt to version their training data. Software teams used Dolt to add version control to their application.
But what’s really exciting for us is that agentic AI needs version control. Dolt allows you to build Cursor for anything. We’re in for an exciting next couple years.
That said, when should you not use Dolt as your database? Over the almost eight years we’ve been building Dolt, we’ve run into a number of use cases Dolt wasn’t a good fit for. We’ve also seen teams stumble over some roadblocks when adopting Dolt. This article explains some reasons not to choose Dolt as your database.
Control#
Dolt requires you have a certain amount of control over your software. Dolt is a standalone database akin to MySQL or Postgres. A server running Dolt is required, either self-hosted or hosted by us in AWS or Google Cloud. Your software will need to connect to Dolt and issue SQL statements. To take full advantage of Dolt’s version control features, your software or an operator must issue additional SQL statements beyond those already issued in most applications.
If you’re locked into a database vendor, Dolt is not for you. If you’re using off-the-shelf software with no ability to make code changes, Dolt is probably not for you. If another team runs databases at your company, you may need to convince that team to run Dolt for you.
Can’t Migrate#
It is difficult to add Dolt “on top of” an existing database solution. In most cases, you must migrate your data from an existing database to Dolt. If your existing database is MySQL or Postgres, Dolt and Doltgres offer compatible solutions. Simply dump your data and import the dump into Dolt. This is still a migration but a simple one. If your data is another form, a migration with data transformation is required. If you can’t migrate from your existing database solution, Dolt is not the right database for you.
Without a migration, the best we can offer is a Dolt replica for MySQL, MariaDB, or Postgres. Dolt can consume a standard MySQL Binlog or Postgres Write Ahead Log (WAL) to produce a replica. Every transaction commit on the primary becomes a Dolt commit on the replica. This Dolt replica can be used for a number of use cases including audit and rollback.
Can’t Change Application Code#
To take advantage of Dolt’s version control features, your application or an operator must run custom SQL queries against Dolt. Dolt’s version control functionality is exposed via SQL procedures, functions, and system tables. To integrate version control into your application, you must modify the application to run additional SQL, then parse and display the results to the user. Necessarily, if you want version control features in your application, you must change the application code to do this.
If you do not control the application code, you can still expose version control features to an operator directly via a SQL connection or via a standalone application. You migrate your application to Dolt and enable the dolt_transaction_commit setting. This setting makes all of your transaction commits Dolt commits as well and requires no code changes in your application. These Dolt commits form the basis of the version control functionality of your database. You then can use other version control features via Dolt’s procedures, functions, and system tables. This can also be done with a Dolt replica, avoiding a migration.
Your DBA Says No#
In many companies, the people who build software are not the people who operate it. Databases may be run by Database Administrators (DBAs), Developer Operations (DevOps), or Site Reliability Engineers (SREs). These people may not be familiar with Dolt and may be hesitant to adopt and operate new database technology. I wrote a whole article about all the questions these folks tend to have and how we answer them. Feel free to reuse my responses or just send your DBA the article.
Complexity#
If you are looking for a simple solution to a small versioning problem, Dolt is probably not the database for you. Dolt is built using the Git model, complete with its renowned complexity. Moreover, as discussed above, Dolt is a standalone database so some engineering work is required to adopt it.
Git is Complicated#
The Git model is complicated. Dolt shares this model. If you are looking to add audit or rollback functionality to a small set of tables, slowly changing dimension in your existing database may be a better choice. If you need the full Git model on your database like branches, merges, or clones, Dolt is the only choice.
Some Assembly Required#
As discussed above, Dolt will require some building. You’ll probably need software engineers, Claude Code, or an App Builder to get an application working using Dolt. Dolt is not an off-the-shelf solution to many business problems. Dolt is a foundational building block you build on top of.
Wrong Database Type#
Dolt is an online transaction processing (OLTP) database. Dolt comes in two SQL flavors: MYSQL and Postgres. Generally, OLTP databases are used to power applications. There are many other types of databases. Dolt is not the right tool for you if you require another type of database.
Data Warehouse#
Another major category of database is the Online Analytics Processing (OLAP) database. These databases are sometimes referred to as data warehouses or data lakes. Adding version control to a data warehouse makes a lot of sense but potentially not in the Git model. For instance, a clone of a data warehouse doesn’t make that much sense.
Common OLAP databases are Snowflake, Databricks, and Clickhouse. These databases are generally used for analytics data or “big data”. The storage engine of this type of database is optimized for large read-oriented workloads whereas OLTP databases are optimized for concurrent read and write workloads. Dolt can be used for analytics workloads but only at small to medium scale. Dolt is not an OLAP database.
Dolt can be used to augment OLAP workloads as a tool for data quality control or to version golden tables.
If you are looking to add version control to your data lake, check out LakeFS. We’ve been following their work since 2021.
Spreadsheet#
There are no version-controlled spreadsheets. Some users see Dolt and especially DoltHub and imagine these tools as a replacement for a complicated Excel Spreadsheet or Google Sheet. This works for some use cases, but Dolt at its core is a SQL database not a spreadsheet.
Graph#
Another category of databases is the graph database. SQL databases perform poorly with graph-like data. Graph traversal tends to be recursive. The combination of tables and SQL does not lend itself naturally to this type of data. That said, Git famously relies on a commit graph. Version control itself often involves graph queries. TerminusDB exists in this category and is generally preferable to Dolt if you need a graph database.
If you are firmly wedded to the idea of using Dolt for graph data, JSON column types can provide some of the functionality. Dolt is especially good at storing and querying JSON, especially for large objects.
Embedded#
Another popular form of database is an embedded database. SQLite is the most popular embedded database. SQLite is vended as a C-library, making it usable in any language without running a server. Files are written directly to disk via the library, thus providing a SQL database directly in your application.
Embedded databases are popular in mobile apps because mobile operating systems offer very restrictive process control. Decentralized version control could help solve the synchronization with mobile apps which are often offline for extended periods of time. Thus, we often get asked for an embedded version of Dolt akin to SQLite. Dolt is written in Golang so Dolt can be embedded in Golang applications but not other languages. This makes Dolt a bad fit for the iOS ecosystem in particular.
Horizontally Scalable OLTP#
Modern OLTP databases, like CockroachDB, Neon, and PlanetScale, separate storage from compute. This allows for databases to get arbitrarily large as load is spread over as many computers as required. Dolt does not do that. Dolt has a traditional scaling model like Postgres or MySQL. If you have a ultra-high scale use case, prefer a horizontally scalable database. There are no horizontally scalable, version-controlled databases but Neon supports forks.
If you would use Postgres or MySQL for your use case, Dolt will work well. Dolt is now as fast as MySQL on sysbench, a good indicator of Dolt’s performance and scaling capabilities.
Wrong Version Control Type#
As mentioned, Dolt is built on the Git model of version control. If you are trying to keep Dolt data synchronized with code in another version control model, like that of Perforce, the model differences become very challenging. We had a customer in the video game industry try to sync Dolt data with their code in the Perforce version control model. It did not go well. Long-lived branches are an anathema in Git but are perfectly fine in Perforce. Certain merges would work in Perforce but would not work in Dolt.
Code in Git and data in Dolt can be synchronized easily in a number of ways. Dolt works well in this case.
Conclusion#
We obviously want you to use Dolt. But sometimes, it is just not the right tool for the job. Do you have a Dolt use case you want to discuss? Come by our Discord and tell us about it.