Then, if anything changes you know it's been mutated because the computed signature has changed.
https://docs.microsoft.com/en-au/azure/azure-sql/database/le...
It's a little harder than you might think to make a database with tamper resistance.
In my mind the only way to guarantee is to maintain a copy yourself and check against the "original", but if you're going to do that, then what I described is sufficient, no?
I only mention this because the project mentions that the history is protected by clients, which I imagine is similar to what I'm describing, e.g. copying and checking against the original.
The attacker in that case could update your copy. But you have somewhat started to fix the issue.
To cover the case where a bad admin has access to the DB and any copies, you need to send a hash every so often to an outside source. In this case they use clients (I'm not sure exactly how they do this).
In fact you need a list of hashes one for every 100 rows for example. Re-generated the hashes and checking against an external source should detect a tamper.
In the case of Bitcoin (which is extremely tamper resistant) every node operator is a validator. The hashes are stored in a merkle tree.
"You can [...] never change or delete records."