Infrastructure

Attachments & storage: when SuiteCRM feels slow

29 October 2026·approx. 14 min read

In short

Slowness has several causes; file volume is common, but not the only one. Measurement beats guesswork.
Backups, staging copies and disaster recovery become more expensive and slower as attachments accumulate — often before users perceive UI latency.
Object storage shifts load and responsibility: permissions, network, lifecycle and traceability must all be considered.

Scenario A · Everything local on the application server

Growth remains on the CRM host

• DB + files share backup windows
• Staging copies become more expensive as volume grows
• Disk requirements and I/O on the application server grow too

Suitable for manageable volumes and clear archiving discipline. Uncontrolled growth makes every failed attempt more expensive.

Scenario B · Object storage for binary data

Separate the application from binary storage

• The CRM host retains metadata and logic
• Large files in S3-compatible storage
• Redesign the backup and restore strategy

Useful when volume and operations justify it, including permissions, lifecycle and network paths. It is not an automatic choice for every small instance.

Illustration: in many installations, files and attachments account for more volume than the core tables. Measure your own paths — there is no blanket 90% claim for every instance.

“SuiteCRM is slow” is an observation, not a diagnosis. Technical causes include CPU, the database, missing indexes, blocking cron jobs, custom code — and growing volumes of binary files . This article focuses on files and storage without ignoring other causes.

1. What is actually growing?

Typical drivers:

Email and document attachments in customer records
Imported historical data and scanned archives
Versioned files without a deletion or archiving policy
Logs and temporary files that nobody rotates

The database may look lean while the upload volume dominates the host — or vice versa. Without two figures (database size and the filesystem size of the relevant paths), discussions remain political.

2. Operational impact

Area	Effect of large attachment volumes
Backup	Longer windows, more expensive media and less frequently tested restores
Staging	Copies take time; teams work with outdated partial data
Migration/upgrade	Every failed attempt costs more time
UI	Not always; depends on access patterns and search

3. Follow a decision process before choosing tools

Measure: Largest directories, growth over 90 days and largest modules.
Classify: must remain online / may move to nearline / may be deleted (with legal approval).
Process: Who may upload large files? Are quotas or usage guidelines in place?
Technology: keep local, archive or use object storage — with an operating model.

4. Object storage: opportunities and costs

S3-compatible storage reduces load on the application server and scales capacity differently from a local disk. The cost is organisational:

Network path and latency to storage
Access permissions and key rotation
Lifecycle (abort multipart uploads, Glacier/cold storage, deletion policies)
Traceability: which CRM record points to which object?

For small instances with a stable 20 GB of attachments, “a tidy local disk + a tested backup” may be a more appropriate solution than an unnecessarily complex storage architecture.

SuiteOffload addresses controlled offloading to private, S3-compatible storage in SuiteCRM. Evaluate it when file volume and backup practices justify it — not as an automatic response to every performance complaint.

SuiteOffload ↗

5. Always check these in parallel

If the UI stalls, also check slow queries, missing indexes, cron backlogs, PHP memory/timeouts and synchronous custom code in save hooks. Optimising storage alone while a hook blocks every save wastes the project effort.

← Back to magazine