Can people who use Dolt explain their use case? Dolt competes with Flyway and Bytebase, but it requires you to run their forked database? Schema migration is unpleasant and not something I can imagine doing willy-nilly like a git commit.
We don't really compete with Flyway and Bytebase. Schema migrations are but one aspect of a versioned database. We version everything, from the schema to the data. You can read more here:
A lot of products have come out that attempt to tackle schema versioning, but none have tackled data versioning before Dolt (https://github.com/dolthub/dolt). In addition, our database isn't forked, it's a full, bespoke solution that can operate as a drop-in replacement for MySQL (Dolt) or PostgreSQL (DoltgreSQL). It's honestly quite exciting technology, so definitely feel free to ask any more questions if you're curious to learn more!
One of Bytebase authors here. I learned Dolt a while back (memorable name).
I think Dolt is closer to Neon/Xata. But still there are differences.
IIUC, Dolt is bringing the database feature to Git, while Neon/Xata is bringing the Git feature to database.
Speaking of Bytebase, if Dolt is really good at versioning schema migration, Bytebase value proposition will be a bit less attractive, but not much. It's similar to the Git story, regardless how powerful Git is, people still need GitLab/GitHub for the developer workflow on top of the mere versioning.
I just learned of Neon a few weeks ago. From the looks of it, Neon supports branching, but it doesn't support merging. Xata supports both branching and merging, however it only applies to the schema.
Dolt (and eventually DoltgreSQL) handles everything. Branching, merging, diffing, cherry-picking, commits, and more. Working with both the schema and data. On top of that, we also have DoltHub (https://www.dolthub.com/) that's analogous to GitHub, and DoltLab (https://www.dolthub.com/#doltlab) that's analogous to GitLab. We are targeting the entire ecosystem from the bottom up.
While version control may be useful, many people already have a managed database, ruling out your solution. If only Dolt could be an extension. If I ever need to run my own MLOps Metadata database, I will consider Dolt though:
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:
We don't really compete with Flyway and Bytebase. Schema migrations are but one aspect of a versioned database. We version everything, from the schema to the data. You can read more here:
https://www.dolthub.com/blog/2022-08-04-database-versioning/
A lot of products have come out that attempt to tackle schema versioning, but none have tackled data versioning before Dolt (https://github.com/dolthub/dolt). In addition, our database isn't forked, it's a full, bespoke solution that can operate as a drop-in replacement for MySQL (Dolt) or PostgreSQL (DoltgreSQL). It's honestly quite exciting technology, so definitely feel free to ask any more questions if you're curious to learn more!
Here is a link to a few use cases as well: https://www.dolthub.com/blog/2022-07-11-dolt-case-studies/
One of Bytebase authors here. I learned Dolt a while back (memorable name).
I think Dolt is closer to Neon/Xata. But still there are differences.
IIUC, Dolt is bringing the database feature to Git, while Neon/Xata is bringing the Git feature to database.
Speaking of Bytebase, if Dolt is really good at versioning schema migration, Bytebase value proposition will be a bit less attractive, but not much. It's similar to the Git story, regardless how powerful Git is, people still need GitLab/GitHub for the developer workflow on top of the mere versioning.
I just learned of Neon a few weeks ago. From the looks of it, Neon supports branching, but it doesn't support merging. Xata supports both branching and merging, however it only applies to the schema.
Dolt (and eventually DoltgreSQL) handles everything. Branching, merging, diffing, cherry-picking, commits, and more. Working with both the schema and data. On top of that, we also have DoltHub (https://www.dolthub.com/) that's analogous to GitHub, and DoltLab (https://www.dolthub.com/#doltlab) that's analogous to GitLab. We are targeting the entire ecosystem from the bottom up.
While version control may be useful, many people already have a managed database, ruling out your solution. If only Dolt could be an extension. If I ever need to run my own MLOps Metadata database, I will consider Dolt though:
https://docs.dolthub.com/introduction/use-cases/data-and-mod...
I was once thinking about where could I use this tool, but nothing really came to my mind. Any interesting use cases or stories to share?
We've got a blog about a few use cases that you might find interesting.
https://www.dolthub.com/blog/2022-07-11-dolt-case-studies/
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:
https://dolthub.awsdev.ld-corp.com/blog/2023-10-11-four-9s-c...
I guess, you can query your data's history like how Wikipedia did. And you could revert it.