Лучше всего использовать для хранения логов отдельную БД,предназначенную для этих целей, иначе вы рискнуете очень быстро получить ситуцию, когда таблица с логами будет занимать больше места на диске, чем все остальные таблицы с бизнес данными, вместе взятые. Это неминуемо приведет к проблемам с администрированием такой базы, бэкапы станут больше по размеру, будут делаться дольше и т.д.

В качестве БД для логов лучше всего использовать Click House - базу от Яндекс. Она отлично для этих целей подходит и невероятно хорошо сжимает данные, т.е. помимо всего прочего, еще и на диске эти данные будут не много места занимать. Также вы можете с Click House настроить полтики хранения данных, например указать что данные в таблице лога должны храниться 5 лет, и CH будет сам их чистить.

Нужно также учесть, что если вы хотите сделать хранение лога транзакционным, т.е. гарантировать, что не будет ситуации, когда у вас бизнес данные поменялись, а при запили в лог упала ошибка, и данные не были залогированы, то нужно вести запись в CH в два этапа. Нужно продублировать таблицу для ведения лога в вашей транзакционной БД, и писать в нее информацию о действиях пользователей в одной транзакции с изменением бизнес данных. Далее нужно реализовать джобу, которая в фоне например по расписанию, или иным образом, будет скидывать данные из лог таблицы в транзакционной БД в таблицу ClickHouse, затем удалять данные в лог таблице транзакцонной БД, только после их успешного переноса в CH. Таким образом таблица с логами в транзакционной БД всегда будет маленького размера.

См. также паттерн Transactional Outbox