A New Database Inherits Someone Else's Retention Decision

When you add a database to an instance that already exists, you also adopt every decision that instance has made, and the one most likely to go unexamined is how long its backups are kept. Nobody chose a retention period for your new data. It was chosen, or defaulted, for something else, long before your data arrived. If the records you are about to store carry any legal or contractual obligation to be kept, that gap is yours to close, and the moment to close it is before the first row is written.

I ran into this shape of problem while reviewing where a new service should keep its data. The sensible, economical answer was to reuse an existing managed PostgreSQL instance and give the new service its own logical database on it. One instance, separate databases, separate credentials. That is a perfectly good design and I'd make the same call again. But it has a side effect that is easy to miss: the instance is the unit of backup, so the new database simply shows up inside a retention window that was set for the tenants already living there. In this case that window was seven days.

Seven days is a very reasonable default for recovering from a bad deployment or a fat-fingered delete. It is a poor answer to a different question: how long are we required, or expected, to keep this information? Those are two separate problems that happen to share a setting. Operational recovery asks how far back you need to rewind after you break something. Retention asks what the business, a regulator or a contract says you must still be able to produce next year. A short window serves the first and says nothing about the second. In the conversation I was part of, the realisation was simply that the retention figure on the console might not be long enough for the legislation that applies to this kind of record, and that nobody had yet written down who would decide.

Why it hides so well

The cloud console makes this easy to overlook, and not through any fault of its own. It shows you an instance. It does not show you the databases inside it as first-class things with their own policies, because they don't have their own policies. You can open the instance, see a healthy backup configuration with a tick next to it, and conclude that your data is covered. Technically it is. It is covered by someone else's definition of covered.

A database administration tool will cheerfully list every database on the instance, which is useful, but it answers a different question. One view tells you what exists. The other tells you what protection applies. Only by putting the two side by side do you see that a new tenant has moved into a house whose lock was fitted for the previous occupants.

This is also why the problem rarely surfaces in testing. Everything works. Restores work. Nothing is slow. The failure only becomes visible much later, when someone asks for a record from eight months ago and the honest answer is that it no longer exists anywhere. That is a terrible way to discover a requirement, because by then the loss is permanent and nobody can point at the change that caused it.

Retention is a data decision, not a storage setting

I've come to think the framing matters. If retention lives in the infrastructure conversation, it gets treated as a cost knob: longer retention costs more storage, so keep it short. If it lives in the data conversation, the questions change. What is this information? Who relies on it afterwards? What happens to them if it is gone? Is there a period we are obliged to hold it for, and is there also a point at which we are obliged, or at least wise, to let it go?

That last part deserves equal weight. Keeping everything forever is not the safe default it appears to be. Longer retention means more copies of sensitive information sitting in more places for longer, which is more exposure for the people who trusted you with it. The goal is not the longest window; it is a deliberate one, with a named owner who can explain the reason for the number.

What I would do differently by default

The practical change is small. When a new database is placed on shared infrastructure, treat retention as part of the placement decision rather than something inherited from it. Write down the period the data needs, compare it with what the instance actually provides, and either accept the difference knowingly or change the arrangement. Changing it might mean extending the instance's window for everyone, taking separate snapshots for the new database, or exporting on a schedule to somewhere cheaper and longer lived. Each has a cost, and the cost is a fair thing to argue about. What isn't fair is arriving at the argument by accident, after the data is gone.

There's a commercial side too. Sharing an instance saves real money and real operational effort, and that is a legitimate reason to do it. But the saving is only genuine if the shared arrangement meets the strictest requirement of anyone on it. If one tenant needs years of history and the others need a week, the instance either carries the longer period for all of them or it isn't really shared in the way the invoice suggests.

None of this is complicated. It is the sort of check that takes ten minutes when it is asked in advance and months of regret when it isn't. The useful question to carry into any "we'll just put it on the existing one" conversation is short: whose retention decision is this data about to live under, and did anyone make it with this data in mind?