Regarding the new object revisions and report usage tracking in 3.5.x, is there any available information on how these may affect database growth?
Report usage tracking is optional and per report. It’s not recommended to enable that on every report in the system. That should be reserved for specific reports that you want to monitor usage of, or problem suspects which you think may be long running and contributing to system slow down overall. With that said, there is a new table specifically to track report run history, and this table will grow by one row for every instance of a report run.
For object revisions, new versions are generated for all metadata upon save or publish (depending on the type of metadata). Versioning tables were added which match all of our respective metadata storage tables, so the table number will increase as a result. However, from a storage perspective, it will only store the specific changes made per version (not all metadata information every time). So if you change a property for a field in a BO and republish, you’ll get one row to represent that change and information about the version. There is no fixed or precisely quantifiable impact to database growth. It’s very dependent on how the system is used, how volatile metadata is, metadata composition, etc.
This is similar to the language tables which exist for every localized BO. This added a lot of tables, but the actual rows of data in the table depends on the amount of languages used (and from a storage perspective, the data for languages will generally be much larger than version changes).
[Admin: This post is related to the 10.31.16 post about using the Report Run History to track performance.]