Hello ssonderman and thanks to and Kyle R and Jon Israel for their input.
to add to that track
We do audit_log on both insert and update and we either have increased the number of object to be audited as per our policy requirements.
With correctly sized architecture we don't have noticeable performance degradation with audit be turned on (as an MSP we run significant amount of separate instances and some of our setup are more that significantly large compare to yours).
The most important part as mentioned by Jon and Kyle is the grow of the audit_log so this is important to have procedure to purge that table frequently to the minimal need for online access and move those data to an offline reporting DWH for historical perspective and be compliant with your company auditing policy.
The purge of the table accomplish 2 things:
- keep the table size acceptable for disk usage and related costs.
- increase query performance when trying to retrieve data by viewing the log in the GUI. There is mostly no impact on the others (like update any object) as insert operation are well optimize in modern SQL and straight forward.
Note that for better performance you can also dedicate a SDM virtual dbagent for that table using parameters in the nx.env at the cost of the RAM for it (around 10mb per agent if I recall but also depend on your cache settings).
So to summarize from my experience the auditing is not a big deal in condition you keep it to the real business requirements, size and finetune your architecture according and correctly define procedures to keep MDB healthy.
just my 2 cents, Hope this help to make your own opinion.
/J