Sakai currently stores "events of interest" in the database in a table named SAKAI_EVENT and never deletes them. This table naturally tends to grow very very large, and yet is very rarely (if ever) used after a user's session is closed.
It's standard industry practice to handle generic event tracking with server logs. Sakai logging is easily and openly configurable. XML-formatted logs can be produced by log4j, and tools (e.g., Apache Chainsaw) are available to analyze them. Logging is designed for cheap writing, and in most deployments will not appreciably interfere with runtime performance to the same extent as database writes. Finally, significant events are likely to be logged by the normal logging system already anyway.
However, if database-based event logging continues to be supported, at the very least it must become much more configurable. There must be some way to filter which events get logged and when they get deleted.
(The more transient and active use of the SAKAI_EVENT table is as a home-grown approach to inter-component messaging. In the short term, the table might still be used for this purpose but cleaned up when messages have been delivered to interested parties. In the long term, Sakai inter-component messaging should be redesigned to use a more standard approach with less overhead.)