How much storage does a typical Mirth Connect deployment actually need?

This varies enormously based on message volume, average message size, and how much content you retain, so there's no universal figure. Project based on your own actual expected volume rather than assuming a generic industry benchmark applies.

Should I prune message content but keep metadata indefinitely?

This is a common and reasonable approach for many organizations, since metadata alone often satisfies audit needs while consuming a fraction of the storage that full message content requires, though confirm this meets your specific compliance requirements first.

When should I move from the embedded Derby database to an external one?

Generally once message volume or the need for better backup tooling and performance outgrows what the embedded default comfortably handles, which varies by deployment but often becomes noticeable well before storage capacity itself is the limiting factor.

Does retention policy need to be identical across every channel?

No, and it often shouldn't be — channels carrying different data types or subject to different compliance requirements frequently warrant genuinely different retention periods rather than one uniform policy applied indiscriminately across your entire deployment.

How do I know if my database indexes are actually adequate?

Watch for query performance degrading as the table grows, particularly around pruner runs or dashboard loading, which often signals missing or inadequate indexes on the columns those specific queries filter by most heavily.

Can I change my retention policy after data has already accumulated?

Yes, you can adjust pruner rules going forward at any time, though changing the policy doesn't retroactively prune data already exempted under the old rules unless you explicitly configure a one-time cleanup pass to address it.

Mirth Connect Database Sizing and Retention Guide

TL;DR

Mirth Connect database size grows in direct proportion to message volume and how much of each message you retain. Project growth from realistic volume estimates, separate content from metadata retention, and confirm compliance-driven minimum retention periods before finalizing pruner rules. Balance storage cost against genuine audit needs, consider archiving before deleting, and document the policy clearly. Size infrastructure — embedded Derby vs. external database, indexes, growth monitoring — ahead of need rather than during a capacity crisis.

Quick answer

Mirth Connect database sizing and retention decisions made at initial setup tend to get revisited under pressure later, usually once storage costs climb unexpectedly or an audit reveals a gap in what was actually kept. Getting this right early avoids both the wasted storage cost of over-retaining data indefinitely and the compliance risk of pruning something you genuinely needed to keep.

Below is how message volume drives database size, how to set a retention policy that fits your real requirements, and how to size infrastructure appropriately from the start. Our free Mirth Health Check can review your current setup — part of the Mirth Connect support work we do for US healthcare teams.

How Message Volume Actually Drives Database Size

Database size grows in direct proportion to message volume and how much of each message you retain, so understanding this relationship early prevents the unpleasant surprise of a database that's outgrown its original infrastructure sizing far sooner than expected.

Estimate Growth Based on Realistic Volume Projections

Project your database growth using realistic message volume estimates over the next year or two, not just your current day-one volume, since most organizations underestimate how quickly their integration footprint actually expands once live.

Understand the Difference Between Content and Metadata Storage

Message content, the actual payload, typically consumes far more storage than metadata like status and timestamps, so a retention policy that prunes content while keeping metadata can dramatically reduce storage needs without losing audit visibility.

Account for Channel-Specific Retention Requirements

Different channels often carry different retention needs based on their clinical or business purpose, so avoid applying one blanket retention policy across every channel when some genuinely need longer or shorter retention than others.

Factor In Compliance-Driven Minimum Retention Periods

Certain message types may be subject to regulatory minimum retention requirements that exceed what you'd otherwise choose for storage efficiency reasons, so confirm compliance requirements before finalizing any pruning schedule for those specific channels.

Setting a Retention Policy That Actually Fits Your Needs

A retention policy isn't a one-time decision — it's an ongoing balance between storage cost, audit and compliance needs, and how often your team genuinely needs to look back at older message history for troubleshooting.

Configure Pruner Rules Matched to Real Requirements

Set pruner rules based on your actual, confirmed retention requirements per channel rather than a generic default, and revisit those rules periodically as your compliance obligations or storage budget change over time. See our message pruner not running guide if those rules stop taking effect.

Balance Storage Cost Against Genuine Audit Needs

Weigh the ongoing cost of retaining message content longer against how often that historical data is actually accessed for audits or troubleshooting, since data retained indefinitely "just in case" carries a real, compounding storage cost.

Consider Archiving Before Deleting Older Data

For data you're not ready to fully delete but don't need readily accessible in the live database, archiving to cheaper cold storage before final deletion can reduce active database size while preserving a recovery path.

Document Your Retention Policy Clearly for Audits

Write down your retention policy and the reasoning behind each channel's specific settings, since being able to explain your retention decisions clearly during an audit matters as much as the policy itself being technically correct.

Sizing Your Database Infrastructure Appropriately

Getting infrastructure sizing right from the start avoids both the cost of over-provisioning unused capacity and the performance problems that come from under-provisioning a database that's already straining under real production load.

Choose Between an External and Embedded Database Wisely

The default embedded Derby database suits smaller deployments, but growing message volume generally benefits from migrating to an external database offering better performance, backup tooling, and scaling options than the embedded default provides. See our database configuration guide for the migration path.

Add Indexes to Support Your Actual Query Patterns

Ensure the database has appropriate indexes on columns your pruner and application queries actually filter by, since missing indexes on a growing table can cause performance to degrade sharply well before storage capacity itself becomes a real problem.

Monitor Database Growth Trends, Not Just Current Size

Track database size growth over time rather than checking only current usage, since a steady growth trend gives you advance warning to plan capacity changes before you hit an actual storage ceiling unexpectedly.

Plan Infrastructure Scaling Before You Actually Need It

Build a rough capacity plan projecting when you'll need to scale storage or move to a more robust database platform, so that decision happens on your own timeline rather than during an urgent capacity crisis.

When to call for help

If your database has already grown past what you expected, the fastest path is usually a targeted retention policy fix rather than an infrastructure overhaul. Our free Mirth Connect health check reviews your sizing and retention setup as part of the standard diagnostic.

Book a Free Health Check →

Troubleshooting something specific? Send us the log, or check pricing for ongoing support plans.

Mirth Connect Database Sizing and Retention: Getting It Right Early