[Question]: storage backend capabilities and options

[datenheim]

What is your question?

Where/how are all the original eml-files stored? Not inside of the postgres DB?

I'd have to handle 500 GiB or more within 20 mailboxes, >8 millions of individual messages with a lot of attachments,
(some large, many small, maybe 10% of emails have attachments, attachments consume maybe 30% of total storage).

Would be nice to be able to put that eventually on a compressible filesystem.

PS: would you consider opening the discussions-feature? I have some ideas that could need brainstorming before becoming an effective ticket.

Application Version

2601.3

[georgejung]

Was wondering this myself. I would like to seperate the DB out from the file storage side of things on different zfs pools. Perhaps its a seperate issue , but having a scheduled job to export to a separate storage, or via a CLI could work...

[luixo]

@s1t5
Backing up 1m text messages is quite different from backing up additional 10k attachments in the same database.
Can I propose giving an option of keeping attachment off the db on some kind of storage?

More in the details:

• add an interface to work with attachments (get, put, delete) in an async way, provide implementation for PG bytea
• add option(s) for storage attachments (filesystem, s3, we can start with a single one) via env variable(s) and implement
• on startup, add a task to loop over the attachments and start migration for every one not in the targeted storage attachment; add "storageType" and "storagePath" when done
• add a way to trigger migration job to the UI

I can work on that if you're down with the idea