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.
Just want to point out that we're announcing development on the project. It's absolutely not ready for mainstream use yet! We have Dolt (https://github.com/dolthub/dolt) which is production-ready and widely in use, but it uses MySQL's syntax and wire protocol. We are building the Dolt equivalent for PostgreSQL, which is DoltgreSQL, but it's only pre-alpha.
> The engine is free and open-source. You can buy support, but these are free products.
Sure, but my question was about the feasibility of selling support to Wordpress users vs PostgreSQL users. The latter usually care more about advanced features such as the ones Dolt offers.
Don't get me wrong; I think Dolt is a great product. I was simply replying to the 2023 stats posted by k1ns.
At the moment, it does not exist for DoltgreSQL as it is in pre-alpha. Dolt (https://github.com/dolthub/dolt), however, may be a better fit for your use case.
This seems so obviously useful and surprising it's taken industry so long to get here. But honestly I'm hesitant to go for something that isn't like a wrapper around the underlying database, just because those are notoriously difficult to implement correctly. Postgres has been around a long time, and has been battle tested, etc.
Yes, it's definitely an uphill battle to launch a new DB for this reason. Our current customers are people who need version control bad enough they're willing to take a chance on a younger implementation.
That said, we have 99.99% correctness according to sqllogictest:
This is interesting, I've never heard of VMDS before. Someone else on the team may have, but I have not personally. From a quick glance at the linked Wikipedia page, it looks like this was created around the same time as SQL, and therefore has a different interaction model. It also predates a lot of modern version-control software like Git, SVN, and Perforce.
So it looks like VMDS is a rather unique take on versioning data, where data is viewed as objects. Dolt and DoltgreSQL use the table and row paradigms that the majority of modern relational databases use. Dolt is designed to be a drop-in replacement for MySQL, and DoltgreSQL for PostgreSQL, so that already determines the interface. Regarding VMDS' versioning functionality, I see that is supports merging and conflict resolution at the transaction layer, but I'm not seeing anything similar to the concept of branches, which is something that Dolt and DoltgreSQL supports.
Overall, for modern use cases, it doesn't look like they overlap much. VMDS seems focused more on the spatial case while representing data as objects, while Dolt and DoltgreSQL are traditional relational databases that support versioning all aspects of a relational database.
