No. Official and legal records detest the in place changes, love a full history of changes, and also love to walk the entire history of changes back. You do not have to convince me, you can talk to the state auditors instead to get their perspective.

Consider two simple and common scenarios (there are more): citizenship certificates and the recognition of prior learning.

1. Citizenship – the person with the name of Joanna Doe in the birth certificate was issued with a citizenship certificate in the same name. As time goes by, Joanna Doe changes the legal name to Joanna Smith; the citizenship certificate is reissued with the new legal name. We do not want to truly update the existing record in the citizenship database and simply change Doe -> Smith as it will create a mismatch with the name in the birth certificate. If we use a ledger database, an update operation will create a new revision of the same record and all subsequent simple query operations will return the latest updated revision with the new name. The first revision, however, will still be retained in the table's cryptographically verifiable audit/history log.

Why should we care? Because Joanna Smith can accidentally throw their new citizenship certificate away and later they will want to renew their passport (or the driver's licence). The citizenship certificate may be restored[0] by presenting the birth certificate in the original name and the current or expired passport, but the passport is in the new name. From a random system's point of view, Joanna Doe and Joanna Smith are two distinct individuals with no apparent link between them. However, the ledger database can provide proof that it is the same person indeed because the unabridged history of name changes is available, it can be queried and relied upon.

2. Recognition of prior learning – a person has been awarded a degree at institution A. Credits from Institution A contributed to a degree at Institution B. The degree at B is revoked due to issues with source evidence (i.e. Institution A). The ledger database makes such ripple effects deterministic – a revocation event at B triggers rules that re-evaluate dependent awards and enrolments at partners, with a verifiable trail of who was notified and when. If Institution A later corrects its own records, Institution B and downstream bodies can attach a superseding record rather than overwrite, preserving full lineage. The entire drama unfolded will always be available.

2½. Recognition of prior learning (bonus) – an employer verified the degree on the hiring date. Months later it is revoked. The employer can present a ledger proof that, on the hiring date, the credential existed and was valid. It reduces dispute risk and supports fair-use decisions such as probation reviews rather than immediate termination.

All this stuff is very real and the right tech stack (i.e. the ledger DB) reduces the complexity tremendously.

[0] Different jurisdictions have different rules but the procedure is more or less similar amongst them.

I have heard an argument for git before, and it is a viable fit for some use cases.

The problem, however, stems from the fact that the git commit history can be modified, which automatically disqualifies git in many other use cases, e.g. official government-issued documents, financial records, recognition of prior learning, and similar – anywhere where the entire, unabridged history of records is required.

No snark required. Whatever the reason for discontinuing QLDB was, it has been replaced with the pgAudit[0] Postgres extension in AWS. I did look into using QLDB for a project involving the management of financial records about 4 years ago and found it to be a somewhat unwieldy to use document database.

Demand for ledger databases is strong in the government and elsewhere where compliance is a non-negotiable. Microsoft have their own on the offer[1] as well.

[0] https://www.pgaudit.org/

[1] https://learn.microsoft.com/en-us/sql/relational-databases/s...

You have responded to the wrong comment. I have presented a case that concerns ledger databases, not the blockchains. If one doesn't understand the difference between the two, it is probably a good idea to refrain from chiming in.