Hierarchical Storage Management (HSM) / Storage Tiering for large deployments

[alepaes1975]

Topic

We have several customers in Zimbra with multi-terabyte mailbox stores. Some of them uses HSM (Hierarchical Storage Management) — the ability to automatically move message blobs older than a configurable threshold (e.g., 6 months) from primary fast storage to a secondary cheaper storage tier (spinning disk, NAS, or object storage), while keeping indexes and metadata on the primary store for fast JMAP/IMAP search.

The key properties of Zimbra HSM that we'd like to replicate:

• Policy-based tiering: messages older than X days/months are moved to secondary store
• Transparent to users: opening an old message fetches it from the secondary store without any special user action
• Fast search preserved: metadata and indexes remain on fast local storage regardless of where the blob lives
• Configurable per-domain or globally

What we've found so far:

Stalwart's architecture (separate blob store, data store, and search store) seems well-positioned to support this. The S3-compatible blob store already exists, but it applies to all messages from day
one — not just older ones.

We considered using S3 lifecycle policies to transition blobs to Glacier after a period, but latency on retrieval makes this impractical for interactive use.

Questions:

1. Is there a planned or existing mechanism to route new message blobs to a local/fast store and migrate them to an S3/object store after a configurable age?
2. Does the Enterprise edition include any archiving or storage tiering features beyond what's in the community edition?
3. If this is not on the roadmap, would a pull request implementing a tiering policy be welcome?

This would be a significant feature for organizations migrating from Zimbra/Exchange with large legacy stores who need cost-effective long-term retention.

Acknowledgement

• I have reviewed the documentation and the FAQ and confirm that my question is not addressed there.
• I understand that maintainers no longer answer support questions through GitHub Discussions, and that for an official response from the Stalwart team I need to post my question at support.stalw.art.
• I agree to follow the project's Code of Conduct.

[github-actions[bot]]

Hi @alepaes1975, thanks for posting!

Stalwart support has moved to support.stalw.art. The support portal is now the canonical place to ask questions, request help, and report issues for triage. Other community members may still reply here, but the maintainers no longer answer support questions through GitHub Discussions, so your question may go unanswered unless you also post it on the portal.

You can sign in to support.stalw.art with your existing GitHub account, so no separate registration is required. Google, Discord, LinkedIn, and email/password sign-in are also available.

Why we are unifying our support channels

Until now, Stalwart support has been spread across GitHub Discussions, Discord, Matrix, and Reddit. As the project has grown, tracking parallel inboxes and deduplicating threads has become unsustainable; the result has been slower answers, repeated work for the people helping out, and good information buried in chat scrollback where the next person with the same question would never find it.

support.stalw.art is a Discourse instance that we operate ourselves, hosted at Hetzner in Germany and GDPR-compliant.

Thank you for helping us keep the conversation in one place.