Newbie here. Questions:
1) Can somebody go over use cases and target customers, where one would prefer this over more traditional DBs.
2) Since this is centralized, it is in theory possible to go back to a previous state of the ledger. Is that blocked simply because the product doesn't support rolling back to a previous state?
1: Use case. Traditional bookkeeping. Asset account balances start at zero initially, then increase with every debit and decrease with every credit. If someone mis-reads a check and enters a deposit as $200 instead of as $20, we do not change the $200 to $20. Instead, we do one of two things: reverse the difference with a $180 credit, or reverse the deposit with a $200 credit followed by a new $20 debit. Traditional DBs support all three approaches: reverse and repost, reverse differences, change the original. If you need to know why the original was changed, in a traditional DB you need an additional audit trail. Implementers can neglect to implement a n audit table. With QLDB, there is no risk that the implementers will choose to update the original deposit, because the database is write-once.
