Your Retention Policy Is a Legal Position: Databases, Legal Holds, and What Actually Gets Produced

Someone sends your company a litigation hold. Suddenly your 30-day PITR window, your partition drop job, your TTL indexes, and your replica lag are not operational details. They are the difference between producing evidence and explaining to a judge why you cannot. I am a court-appointed Special Master and expert witness. Hundreds of federal and state proceedings, including In Re: Facebook. When a dispute reaches the point where someone has to go find out what the data actually said on a given day, I am often the person who does that. Which means I spend a lot of time inside Postgres, MySQL, and MongoDB deployments run by people who never expected their retention config to be read aloud in a courtroom. This is not a compliance talk and there will be no policy templates. It is a set of war stories about what breaks. Why logical replication gaps produce arguments nobody can settle. Why “we have backups” and “we can reconstruct state as of March 14” are unrelated claims. Why TTL indexes and automated partition pruning are the most common way a hold gets silently violated. How binlog and WAL retention decide whether a change is attributable to a person or to nobody. What audit logging looks like when someone is actively looking for the gap in it. You will leave knowing which knobs in your own stack are also legal exposure, what “preserve everything” actually asks of you technically, and how to answer counsel when they ask what you can produce, without promising something your architecture cannot deliver.