3 ms·

It's amazing this isn't a standard feature. The database world seems to have focused on large, high volume, globally distributed databases. Presumably you would

It's amazing this isn't a standard feature. The database world seems to have focused on large, high volume, globally distributed databases. Presumably you would't version clickstream or IoT sensor data. Features like this that are only feasible below a certain scale are underdeveloped and I think there's opportunity there.

fiddlerwoaroof 6y ago
Datomic has some sort of zero-cost forming of the database: it’s “add-only” design makes this cheap.
qbasic_forever 6y ago
Every DB engine used at scale has a concept of snapshots and backups. This just looks like someone making a git-like porcelain for the same kind of DB management constructs.
- zachmu 6y ago
  It's not just snapshots though. Dolt actually stores the tables, rows, and commits in a Merkle DAG, like Git. So you get branch and merge. You can't do branch and merge with snapshots. (You also get the full git / github toolbox: push and pull, fork and clone, rebase, and most other git commands)
  - qbasic_forever 6y ago
    Yeah it's a neat idea but I struggle to think of good use-cases for merge, other than toy datasets. If I'm working on a service that's sharding millions of users across dozens of DB instances a merge is going to be incomprehensible to understand and reason about conflicts.
    - MyNameIsFred 6y ago
      > Yeah it's a neat idea but I struggle to think of good use-cases [...] If I'm working on a service [...] I suspect that's simply not the use-case they're targeting. You're thinking of a database as simply the persistence component for your service, a means to an end. For you, the service/app/software is the thing you're trying to deliver. Where this looks useful is the cases where the data itself is the thing you're trying to deliver.
101008 6y ago
Isnt the mysql log journal* what you are looking for? * I dont remember the exact name but I refer the feature that is used to replicate actions if there was an error.
- fiedzia 6y ago
  No. Relational DB logs are kept for short time, and do not allow for branching/merging. And even if you would store full log since day 1, the only way to check state of database at some point would be to start from scratch and reply everything to desired point. For any sizeable db, that's not practical.
- deleted 6y ago
  [deleted]

fiddlerwoaroof 6y ago

Datomic has some sort of zero-cost forming of the database: it’s “add-only” design makes this cheap.

qbasic_forever 6y ago

Every DB engine used at scale has a concept of snapshots and backups. This just looks like someone making a git-like porcelain for the same kind of DB management constructs.

zachmu 6y ago
It's not just snapshots though. Dolt actually stores the tables, rows, and commits in a Merkle DAG, like Git. So you get branch and merge. You can't do branch and merge with snapshots. (You also get the full git / github toolbox: push and pull, fork and clone, rebase, and most other git commands)
- qbasic_forever 6y ago
  Yeah it's a neat idea but I struggle to think of good use-cases for merge, other than toy datasets. If I'm working on a service that's sharding millions of users across dozens of DB instances a merge is going to be incomprehensible to understand and reason about conflicts.
  - MyNameIsFred 6y ago
    > Yeah it's a neat idea but I struggle to think of good use-cases [...] If I'm working on a service [...] I suspect that's simply not the use-case they're targeting. You're thinking of a database as simply the persistence component for your service, a means to an end. For you, the service/app/software is the thing you're trying to deliver. Where this looks useful is the cases where the data itself is the thing you're trying to deliver.

101008 6y ago

Isnt the mysql log journal* what you are looking for? * I dont remember the exact name but I refer the feature that is used to replicate actions if there was an error.

fiedzia 6y ago
No. Relational DB logs are kept for short time, and do not allow for branching/merging. And even if you would store full log since day 1, the only way to check state of database at some point would be to start from scratch and reply everything to desired point. For any sizeable db, that's not practical.
deleted 6y ago
[deleted]