Good points. We believe we have fixed the physical-order-and- scraping-issue by using random uuids as primary keys, showing stuff in the UI always ordered by PK, and periodically doing a CLUSTER, which physically rearranges the table after some index (pk in our case).
We haven't thought about higher-order storage layers. I guess we should do that... Thanks!
You need to use another database for this, specifically one designed to always overwrite data in place, and erase the WAL immediately after commit: it should be easy to write it yourself, assuming the dataset fits in RAM and so you don't need any data structures on disk other than a simple array of records.
Also you need to ensure that higher storage layers don't keep snapshots and don't do copy-on-write.
Could also look into a cryptography-based solution, although not sure if there is a feasible one.