However, we’ve seen a number of customers explore Intella using QNAP, Synology, Azure Files, Amazon S3/EFS, and others. While these solutions work very well for general storage, backups, or file sharing, they are not a good fit for active Intella cases. An active Intella case refers to any case that is being actively worked on. This includes indexing evidence, case sharing, searching, filtering, tagging, reviewing, or any other process that requires frequent read and write operations. Intella performs a very high volume of these operations, similar to a database, and these storage platforms are not designed for that kind of workload.
Potential Issues
- Network latency and throughput: Whether accessed via SMB, NFS, or iSCSI, storage traffic is subject to network latency. Even with high-speed links such as 10 GbE, performance is noticeably slower than local SSDs or cloud providers’ local disk options. This is especially true for generic network file shares and object storage systems (including typical NAS appliances), which are designed for general file storage and collaboration, not low-latency, high-throughput database-style access.
- IOPS limitations: Most NAS devices and cloud-based file shares are optimized for capacity and collaboration, not for the high input/output operations per second (IOPS) required by workloads like Intella during indexing and case analysis.
- Reliability under heavy workloads: Network-attached storage devices and cloud file shares can struggle under concurrent, high-intensity database workloads. While higher-end NAS appliances and caching can help, they still don’t match the performance and reliability of local or block-level managed disks.
Why indexing and searching are demanding on storage
-
Latency and throughput: Network storage always introduces delays compared to local or managed disks. Even with high-speed connections, NAS appliances and cloud file shares are designed for general file sharing, not continuous, database-style access.
-
IOPS constraints: These platforms are optimized for capacity and sharing rather than the high number of frequent read/write operations required during indexing, searching, filtering, and tagging.
-
File locking and open file limits: Active cases open and update many files at once. Some NAS systems (such as some Synology NAS models) run a custom Linux-based OS (DSM), which may impose lower default limits on concurrently open files. You’d likely need to increase
ulimit -n
on both the NAS and the client accessing it to avoid hitting system limits. However this is not recommended, since network storage in general can still hit open file limits or locking conflicts, further slowing operations.
When is it suitable?
Better Alternatives
Review the table below for types of discouraged storage, and what Vound recommends as an alternative.Discouraged Storage Types | Example / Notes |
Recommended Alternatives | Notes on Why |
Consumer NAS | QNAP, Synology |
If deployed on-premises: replace with local NVMe SSDs or enterprise DAS/SAN for active cases. If deployed in the cloud: consider moving data to managed block storage (e.g. Azure Managed Disks, AWS EBS Provisioned IOPS SSDs ("PIOPS")) for low-latency, high-IOPS access. |
Limited IOPS, file locking issues, limited number of open files, latency; not suited for active cases |
Cloud File Shares | Azure Files, AWS EFS | Managed Cloud Block Storage (e.g. Azure Managed Disks, AWS EBS PIOPS)¹. | Optimized for sharing/archiving, not continuous database-style access |
Cloud Object Storage | AWS S3, Azure Blob | Managed Cloud Block Storage (e.g. Azure Managed Disks, AWS EBS PIOPS)¹. | High latency, not designed for frequent small-file access |
Cold/Archive Storage | Amazon Glacier, Azure Archive Storage | Local or managed block storage only for active cases; Glacier/Archive fine for long-term archives | Extremely high latency; retrieval times make them unsuitable for active workloads |
Temporary Local Storage | EC2 Instance Store (NVMe) | Local NVMe SSD RAID, enterprise DAS/SAN, Managed Cloud Block Storage (e.g. Azure Managed Disks, AWS EBS PIOPS). | Extremely fast but is only temporary storage; data is lost if VM stops |
Verdict
ulimit -n
), memory-mapped files
(vm.max_map_count
), and total file handles (fs.file-max
) should be increased and persistently tunable.