Dolt is the first version controlled SQL database. DoltHub is a place on the internet to share Dolt databases. DoltLab is a self-hosted version of DoltHub. Dolt brings Git-style version control to the relational database.

Often, Dolt users want a subset of writes isolated from other users. In the standard Git model for source code, you would clone a copy, make your changes on a branch, and then push that branch to your remote for review. This model is called distributed version control. Dolt supports this model. This is the collaboration model we use for data bounties.

However, the clone collaboration model is cumbersome for Dolt use cases where Dolt is being used to back an application, the Online Transaction Processing (OLTP) use case. Users don't want to clone a whole copy of a database and start a SQL server to make writes. For this use case, we diverge from the standard Git model and recommend using a single running Dolt server and branches for write isolation. Dolt ships with a MySQL compatible server and provides version control operations as SQL functions and system tables. For this use case, drop the "distributed" in "distributed version control" and fall back to plain old version control.

This blog goes into greater detail on both Dolt collaboration models to help you choose which one is right for your use case.

Clones

In the clone model of collaboration, you treat the remote as a backup/coordination point, not a running server. Collaboration interactions are generally command line driven. Dolt provides a replica of the Git command line interface.

To start collaborating, you identify the name of the remote database you would like to collaborate on from a remote hosting service, like DoltHub. Then you create a copy or clone of that remotes database using the dolt clone command.

You now have a resource isolated copy of the database to interact with. For read operations, you share no resources with the main copy, so hit that clone with your worst metrics queries, no danger of breaking anything. For write operations, you have complete visibility isolation. No one else can see your changes unless you want them too. Hack away at that database with impunity.

When you want to get updates from the remote database, you use dolt pull. This fetches the remote branch and merges it into your local tracking branch. As long as there are no conflicting updates, you can continue to read and write in isolation without doing additional work. If there are conflicting updates, you must resolve them to continue updating.

When you want to send your updates to the remote database, you use dolt push. This attempts to merge the changes from your local branch into the remote branch. If there are no conflicts, your remote database branch now reflects your local copy.

Pros:

• Resource isolation.
• Constrained Visibility.
• No single point of failure.

Cons:

• Complexity. Lots of instances to manage.
• Command line driven.
• Large storage/network footprint. Each clone is a copy of the database and its history.

Branches

In the branch collaboration model, you run a single Dolt server and collaborate using branches. Unlike Git, Dolt can be run as a server and controlled remotely.

This collaboration model is not intuitive to some because it deviates from the distributed Git model where you almost always operate on a clone. Git is primarily offline and distributed. Dolt can be used offline and distributed like Git. But for most OLTP applications, developers use Dolt online.

Connect any MySQL client and run SQL queries to access version control primitives. dolt branch mybranch becomes select dolt_branch('mybranch'). dolt merge mybranch becomes select dolt_merge('mybranch'). And so on. There are a number of ways to control, change, and merge branches. The idea here is that your application is driving the version control via SQL statements.

The advantage here is that you can have an application or API controlling your database versioning. You can expose these versioning features to your applications users. You get write isolation in the sense that writes will only be seen by users on the writes' branch. But it's all happening against the same server so beware of expensive queries, just like any other OLTP database.

Pros:

• Version control in a running database.
• Use branches for write isolation.
• Full visibility into changes.

Cons:

• No resource isolation.
• Single point of failure.

Conclusion

We imagine both of these collaboration models being used in unison. Imagine using the branch model of collaboration on a clone and then using the clone model for coordination with offline use cases like metrics or debugging. We think this combination of features makes Dolt the next evolution in relational databases.

Agree? Download Dolt and try it today. Or come chat with us on our Discord. We love geeking out about databases.