Our table storage backend is generally modeled around revisioning and MVC. This has many advantages for eventually consistent storage systems & distributed systems, but - if all versions are kept - can also result in a lot of storage used.
We have recently started to manually thin out our renders per revision (T94196) with an ad-hoc script. This is however fairly inefficient and operationally complex. Instead, we should implement a schema-configurable garbage collection policy in the table storage backend.
The schema property used to configure the policy could look like this:
```
{
revisionPolicy: {
type: 'latest',
count: 1,
grace_ttl: 86400
}
}
```
The `grace_ttl` defines how long an entry is kept around after it was superseded. This is useful to let clients finish operations that depend on a specific revision, as described in T94422.
Here is another example keeping one entry every 24 hours (which could be a reasonable choice for Parsoid revision renders):
```
{
revisionPolicy: {
type: 'interval',
interval: 86400,
count: 1,
grace_ttl: 86400
}
}
```
Defaults could be:
- 'latest' for logical tables that don't have an explicit timeuuid property defined in the last index position
- 'all' (keep all revisions) for tables that have an explicit timeuuid property defined in the last index position