> Time-Travel Queries: Query historical data at any point in time:
The example here looks like it may be storing the full history of transactions? Is that right? That's a pretty high cost to pay for something that's not touted as a marquee feature.
I'm working on a DB[1] that stores full transaction history but it's so that I can support decentralized synchronization. It's in service of my marquee feature so I need to pay the cost of storing history, but I'm surprised that Stoolap also seems to be doing it for a local embedded database.
I would imagine (but haven't looked at it at all) that it's a byproduct of an append only data format. Then having a historical PoV is cheap - you simply disregard changes after a certain time.
Append-only has many other benefits, including zero contention between many readers and (single) writers. In the vanilla version, writers still contend though.
I think their point is that system timestamps for that append-only format aren't good enough. You need logical timestamps corresponding to increasing transaction ids.
The example here looks like it may be storing the full history of transactions? Is that right? That's a pretty high cost to pay for something that's not touted as a marquee feature.
I'm working on a DB[1] that stores full transaction history but it's so that I can support decentralized synchronization. It's in service of my marquee feature so I need to pay the cost of storing history, but I'm surprised that Stoolap also seems to be doing it for a local embedded database.
[1] https://github.com/arcuru/eidetica