The idea is:
The ability to store versions of a database periodically automatically. Allowing for revisiting older versions and exporting it also.
This would be nicer than say, cloning that data periodically. E.g. Set up automatic versioning to occur on the 15th of each month, giving a bit of space between when automations run to update the data.
Also allowing for the creation of versions manually would be nice. The versions could be read only, or make that optional.
Perhaps one efficient way would be to make another resource type that is similar to a database ‘mirror’. Allowing us to cherry pick the specific source data we actually want to keep historic info about (e.g. if only some of the columns are needed). Then configure a periodic snapshot and retention policy for that mirror (e.g. monthly, delete copies older than x days/years old).
Likely something comparable can already be done now for databases using an automation, like export the data to a csv and upload it to external storage or via email.
My use case:
I have some table data, which is updated on a monthly basis. These are ongoing calculations that are used for practical operations. It’s not a huge amount of data, but keeping the historic versions is helpful for auditing.
What I am trying to cover is, that once this data is updated for the next month, the previous data is overwritten and lost. Storing the historic data on an ongoing basis could be done by creating additional resources and automations to store the needed parts in a timeseries format - though adds a fair bit of complexity.
If we could, for example, enable automatic versioning on some select resources, it could potentially solve this in a convenient way.