andreasb
Explore posts from serversImmutability & tamper-proofing?
Not sure if this is an interesting note @kostas , but XTDB (an immutable SQL database) is building out their v2.x to have Postgres compatibility (alpha/beta docs): https://pr-3496.d2zcybuz6k9g4m.amplifyapp.com/drivers/postgres/getting-started.html
They're also looking for design partners, in case Xata would like to branch into database-as-a-value thinking (see bottom of their frontpage): https://xtdb.com/
8 replies
Immutability & tamper-proofing?
Another reason why this might be worth your while is the sunsetting of Amazon's QLDB (quantum ledger db) offering, leaving a lot of customers without a proper alternative. AWS' recommendation is Postgres with triggers, but that won't be enough for many cases (such as ours).
8 replies
Immutability & tamper-proofing?
Thanks for the comprehensive answer, @kostas!
For our specific use case, having "just" auditing would maybe suffice, but as long as the audit log tables are mutable (or the triggers disabling updates can easily be turned off), we're back to square one. Having some replication like CDC is basically the same, as long as the target db is mutable the audit/replication cannot be trusted either. The main issue I see with using the audit log is that the database value is no longer the source of truth, but rather the contents of the audit log, so the verification/"reconciliation" of values and log entries can quickly become either a lot of manual work or require quite some engineering.
Our use case is that of a financial application where monetary values and certain amounts/counts are important to easily check if have been (maliciously) mutated/tampered with when they shouldn't have been. Would be the same with a previous health-related application I was contracted on, audit logs are fine but not if they cannot be trusted.
8 replies