Hydrocharged

You can think of Dolt as having 4 layers to it. From the top-most interface to the bottom:

Vitess (Handles Wire Protocol)

go-mysql-server (GMS, Implementation of MySQL featureset)

Dolt GMS interface

Storage Engine

DoltgreSQL, right now, shares the storage engine, interface, and a portion of GMS. This is primarily to get something up and running so that we're able to further iterate on a "working" product (i.e. something we can set up testing for). I envision that GMS will split into three, with a MySQL & PostgreSQL core interacting with a base SQL core. Dolt's GMS interface would then adapt to the base SQL core interface. The storage engine is more-or-less set in stone.

The sqllogictests are better used as a judgement of how accurate our results are to MySQL's results given a very large range of statements (around 6 million tests). They are not, however, indicative of the entire feature set. That's to say, there are a few things that are not yet supported in Dolt, however they are the more esoteric features. Things like transactions, etc. are what I would consider "core" SQL, and we are very keen on making sure those work exactly as you'd expect

There are two key points regarding performance that I'd like to mention, and that's that Dolt uses higher-than-expected disk, and we also use more memory than MySQL by comparison. The disk usage is due to our optimization of speed at the sacrifice of disk accretion via temporary storage, which we've decided is a fair trade off considering disk is very cheap (and we're working on making this tunable so users can decide on speed vs disk efficiency). Memory usage is a bit more complex, and I'm not the employee to comment too much about it, but both of these issues are being worked on to reduce their impact. With that in mind, our performance is comparable to MySQL as long as the machine limits are not being reached, however I'd expect us to be a bit slower once those limits are reached, simply due to the extra complexity that we're managing.

Lastly, trust is something that can only be built over time. In 10 years, I'm sure that there will be no doubt of our stability, and at that time I can see Dolt and DoltgreSQL becoming the de-facto databases used for relational storage. Of course, I may be a bit biased :)

Trust is a

Thank you! :D

This is a fully-versioned database. By versioning, think of how Git applies to text files, and all of the power that comes from that model. You have branching, diffing, merging, etc. It allows you to collaborate with each other, or you can create a brand new project by "forking" an existing one. Now, imagine that model, but applied to a relational database.

There are products that can do something similar for schemas, but DoltgreSQL (and Dolt, the production-ready DB based around MySQL rather than PostgreSQL) applies this to both schemas and data. This is unique to DoltgreSQL and Dolt, and what sets us apart from all other products. One example I like to use that I think really captures this power, is the ability to query data from any commit. We use Git's model of version control, so your database has a commit history and a working set. The working set can be viewed as the "current" commit. When you run queries, you implicitly select the working set, however we expose the ability to explicitly set which commit you're targeting. This means you can do things like run a join query across old and current data!

These situations, and more, and not possible via migration tools, backup tools, or any other kind of tools. This is unique to DoltgreSQL and Dolt, by fully embracing data versioning. This is but one example, and there are many, many more.

You understood correctly! That's just one use case, there are many, many more. Some of which we haven't even considered yet, just because the model is that powerful.

hahn-kev made a really good comparison, but it can go a step further. Not only can you query the data at some previous point in time, but you can even run a join across old and current data. If you look at it from the perspective of commits and working sets, then the working set is just the "current" commit, and commands implicitly target the current commit. We give you explicit control over which commit is being referenced, so there's a lot of power in the model.

Recovery is a valid use-case for version control, but fully applying it to data opens up possibilities that haven't really been explored before.