Even if you have history_days set to zero, document versions are created and stored until the document garbage collector sweeps through your data as a background task.
Storage is effected by
- Document history
- Index history
Index history often surprises people so I think it’s important to note. Any time a change to a document would result in the index being updated (term or value fields changed) the history of the Index is updated. This history is stored since you can use the At function to query an index at any moment in time.
Documents uses a built-in Index, and that index counts towards storage. There are no terms involved, so the
Documents indexes will only store entries for
You can use the Events function on any reference, including Set references. That means you can use it to enumerate the history for your Indexes.
You posted a similar question in Slack; is that for the same database? Either way, we can use that as an example. In that question, you said there are 20 documents and ~7MB storage. But we can also see in that there are 703 Write Ops recorded. In that case, storage might be represented by
- 703 document versions
- plus Index entries from the built-in Documents indexes for creating and deleting documents
- plus Index entries for each update that changes any term or value field.
So, in order to get a more complete picture of how your database is using storage, we would need to know how many indexes you have on your 9 collections, and what terms are used. Then you can query for the history per Index per term.