A common Mirth Connect support call starts with a full disk or a slow Administrator, and ends at the database. The engine stores messages, and unless someone has thought about how much and for how long, it stores a lot of them.
This post covers why the store grows, the settings that control it, and a sensible way to tune them.
What the engine stores
For each message, Mirth Connect can store the raw inbound content, the transformed and encoded content at each connector, responses, metadata, custom metadata columns, attachments, and the state of maps. It keeps these in per-channel message tables in the backing database. A busy channel with full storage writes several copies of every message, plus each destination's output.
Multiply by a few hundred channels and a few years, and the database becomes the largest thing in the estate.
Storage modes per channel
Each channel's message storage setting sets how much is kept:
- Development: everything, at every step. Good for building and debugging a channel; expensive in production.
- Production: enough to reprocess messages and see what was sent, without every intermediate step.
- Raw: the raw inbound message and metadata only.
- Metadata: no message content, only metadata such as status and timestamps.
- Disabled: nothing stored.
There are also options to remove content once a message completes, and to remove attachments.
Two rules of thumb:
- Channels should not run in Development mode in production. It is the single most common cause of runaway growth we see.
- Choose per channel based on what you would need to investigate or reprocess a message. A results feed you may need to resend deserves Production; a high-volume heartbeat probably needs Metadata.
Remember the trade-off: whatever you do not store cannot be reprocessed or inspected later, and cannot be captured for a future migration's parity tests. Decide deliberately.
The data pruner
The data pruner is the background job that deletes old messages. It has a global schedule and per-channel retention settings: how long to keep message content, and how long to keep metadata.
Things to check:
- Is the pruner enabled and running? We regularly find estates where it was disabled during an incident and never re-enabled.
- Does every channel have retention set? Channels with no pruning settings keep everything forever.
- Does the schedule fit the load? Pruning a large backlog during clinical peak hours competes with live traffic. Run it in a quiet window, and work through a large backlog in stages.
- Is archiving needed? If policy requires keeping message history longer than the engine should hold it, archive before pruning, and treat the archive as PHI.
Queues are storage too
Queued messages live in the same store. A destination that has been failing quietly for weeks can hold a large queue that the pruner will not remove, because the messages have not completed. Alert on queue depth so this cannot hide.
The database itself
The backing database needs the same care as any other production database: monitoring of size and growth, regular maintenance appropriate to the engine (vacuuming, index maintenance, statistics), backups that are tested, and capacity for growth. Many estates still run on whatever database was chosen when the engine was installed. If yours is the embedded default, moving to a production-grade database is often worth doing before anything else.
A tuning pass
A practical sequence for an estate that has grown out of control:
- Measure. Size per channel table, message counts, and growth per week.
- Fix storage modes. Move production channels off Development, and set each to the lowest mode that still lets you investigate and reprocess what matters.
- Set retention on every channel, agreed with whoever owns audit and compliance requirements.
- Clear the backlog in stages, outside peak hours, watching database load.
- Drain or resolve stuck queues.
- Add alerts on database size, queue depth and pruner failures.
- Write it down in the channel inventory so the next person does not reset it.
Done carefully, this usually restores Administrator performance and frees significant disk without losing any history that matters.
Where we come in
Message-store and queue growth management is part of our channel operations work, and it is one of the first things our estate assessment looks at, because an upgrade or migration is far easier against a database that has been kept in order.
Chartferry is independent and is not affiliated with, endorsed by, or a reseller of NextGen Healthcare. Mirth Connect is a trademark of NextGen Healthcare, Inc.