Can network-based storage solutions be used with Intella?

Yes, certain network solutions (such as enterprise SANs with block-level access) work well for active cases, as long as they provide low latency, high IOPS, and sufficient file handle limits.

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. 

Although solutions such as the above may work in some situations, we do not recommend their use, as they can cause issues that may be intermittent and/or difficult to diagnose.


Potential Issues

  1. 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.
  2. 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.
  3. 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

Active cases require extremely fast access to thousands of small files simultaneously, similar to a high-performance database. Network-based storage and cloud file shares can struggle under these conditions due to several factors:

  • 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.

Combined, these factors can significantly limit throughput and responsiveness. For active cases, local NVMe SSDs, managed cloud disks, or enterprise DAS/SAN solutions provide the low latency, high IOPS, and robust handling of open files that these workloads require.



When is it suitable?

Network-attached storage devices and cloud file shares are well-suited for backups, archives, or cold storage of completed cases. They are not recommended for active cases, where local NVMe SSDs, managed cloud disks, or enterprise SAN/DAS solutions provide significantly better reliability and performance.


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
¹ Note:
For AWS, FSx for NetApp ONTAP and FSx for Windows File Server may work as shared storage. However, we strongly recommend migrating to Managed Cloud Block Storage instead for consistent low-latency, high-IOPS access.


Verdict

Network-attached storage devices and cloud file shares can be very useful in the right context, but they are better suited for storage, sharing, and archiving than for running active cases. For indexing and ongoing analysis, local or managed disks provide significantly better performance and stability.

For active Intella cases, storage must support high IOPS, low latency, and large numbers of concurrently open files
Enterprise DAS, SAN, or local/managed block-level disks (e.g., iSCSI or NVMe) are recommended, while consumer-grade or general-purpose network file shares (SMB/NFS) are typically unsuitable. System limits such as open file descriptors (ulimit -n), memory-mapped files (vm.max_map_count), and total file handles (fs.file-max) should be increased and persistently tunable.