Best practice for automatically deleting persistent chat data

Runtime Framework
1

Hi all,

We’re using Nakama’s persistent chat messages, which are stored in the database. To keep the database clean and prevent unlimited growth, we’re looking for best practices to automatically delete old chat data.

I’m aware of the Nakama Console option under Chat Messages/Delete Messages:

Are you sure you want to delete all messages before retain days?
Choose how many days to retain: n

However, I’m not sure whether this is the recommended approach for production use, or if it’s mainly intended as a manual / maintenance tool.

For our use case, we’re considering the following policies:

  • Direct messages
    Automatically delete messages after n retain days.

  • In-game / match chat
    Delete messages when the match ends or when the last user leaves the room.

  • Group chat
    Automatically delete messages after n retain days.

Questions:

  1. Is using the Console’s “delete before retain days” feature the intended way to handle this?

  2. Is it better practice to implement a custom cleanup mechanism (e.g. a cron job using server runtime code or direct DB cleanup)?

  3. Are there recommended patterns or pitfalls to be aware of when deleting chat messages (performance, indexes, message history, etc.)?

  4. Is there any built-in automation or retention configuration per chat type (DM / room / group), or is everything global?

Any guidance or real-world experience would be greatly appreciated.

Thanks!

2

Hi @Mathijs-Bakker,

If the chat messages can be ephemeral (as seems to be for in-game matches), I’d suggest you simply use the persist flag to false when calling ChannelMessageSend.

Otherwise, Nakama doesn’t currently provide a runtime function to selectively delete persisted messages in bulk, or granular automated retention policies. The recommended approach would be to call either the console API or a custom RPC using a cron job. The former is a bit limited, it accepts a date or a list of ids, you could use the date as a cutoff to trim messages older than that date, but it deletes from all persisted channels indiscriminately. If you need it to be more fine grained with different retention times based on channel or similar, you’d need a custom RPC with some custom SQL - depending on how granular you want to be in the query, this may have some performance implications depending on current dataset size, you’ll also need to deconstruct the channelId of the persisted messages into its stream_mode, stream_subject, stream_descriptor and stream_label identifiers.

If the current dataset is very large, then the 1st run of this custom RPC may take a bit longer, but I wouldn’t expect it to cause issues since it is to be run every so often by the cron job.

Best.