[jeroiraz]

there are many differences (as immudb contributor): - immudb can be used embedded or client-server database while qldb is a aws service - immudb behaves as a key-value store but also provides SQL support while qldb provides a document-like data model with PartiQL language - immudb provides time travel features - immudb it's faster, built-in with a mode of operation designed for fast writes which works with eventual indexing.

Finally but super important, immudb can be deployed anywhere and it's open source!

[giaour]

QLDB provides time travel features, too (if by "time travel" you mean being able to query the state of a record at an arbitrary point in the past): https://docs.aws.amazon.com/qldb/latest/developerguide/worki...

[jeroiraz]

immudb already included history support for key-value entries in previous releases. But since v1.0.0, immudb provides query resolution at a given point, using the current data on that specific moment but also being able to combine data at different points in time on the same query. Is not clear to me if it's something that can be achieved with “SELECT * FROM history”, it requires up most one result per different entry (the most recent one)

[giaour]

QLDB is a document DB, so you are limited to a single point or range per query. Also keep in mind `history` in QLDB is a function, not just a store of previous values; given a table "foo" and a key "bar", getting its immutable state from last Tuesday at 4 PM EDT would be:

SELECT * FROM history('foo', `2021-05-18T20:00:00`, `2021-05-18T20:00:00`) as t WHERE t.metadata.id = 'bar';

[jeroiraz]

temporal features provided in immudb allows query (and subquery) resolution based on older states of the database. So for instance, it can be thought as retrieving the documents on its current state in a given time range. Querying the history of changes of a given key or document is slightly different and it's also covered with history operation in immudb.

[giaour]

Ok, that sounds extremely similar to the history function in QLDB.

In the examples shown in the AWS docs, the results of a historical query are not changes made to the document, but the fully resolved state of a document at the requested timestamp (or within the timestamp range). Like other threads on this page mention, this is an unusual but not uncommon DB feature these days.