Pros and Cons of Database in a container for EventSentry

EventSentry really only cares that it can reach the database to write data and read data, and that your database storage performs adequately for the amount of events per second that are being written to the database.

For smaller installations you would not need to bother with anything other than the default settings and let EventSentry install and manage the database for you.  Even for most of the medium and large installations, unless your storage is too slow you would only need to optimize the Postgres settings (https://www.eventsentry.com/kb/232) and possibly set up a junction (symlink) to point the Postgres WAL at a separate drive since the Postgres configuration does not allow you to directly specify a WAL location. For Microsoft SQL you'd want to make sure you have optimized autogrowth settings for your MDF and LDF files, and that the MDF and LDF are on separate disks from one another, and other common performance recommendations from the Microsoft SQL documentation.

If you want to do anything else with the database such as containers or clusters, as long as it does not reduce the write performance of the database in your environment, go right ahead.  One thing to watch out for is that if you do clustering directly within Microsoft SQL, it will change the database recovery mode to FULL, which for almost all situations will cause lots of transaction log disk usage/storage problems when you purge from the database.  You'd need to have a script that changes the recovery mode to SIMPLE, purges your data, and then changes the recovery mode back to FULL so that the clustering works again.