Assurance

Assurance as Code in the Database

All code in PostgreSQL should be tested, or assured, with pgTAP code. All Assurance Engineering Cases (AECs) should be written code-first, not human-first (what we call Assurance as Code). If Assurance is done within the database then tools like PostgreSQL Anonymizer should be used to help build test-first databases from production data when appropriate (see this PDF for further elaboration).

Chaos in the Database

Because our responses to bugs in the database which might lead to database crashes is only as good as the number of times we see such crashes, we should use tools like pg_crash, a “Chaos Monkey” Extension for PostgreSQL databases. Per their repo “pg_crash is an extension to PostgreSQL, which allows you to periodically or randomly crash your database infrastructure by sending kill (or other) signals to your DB processes and make them fail. It is ideal for HA and failover testing.”