Total file and directory count: The total number of objects to catalog is the dominant driver of compute and storage requirements. Higher object counts require proportionally more memory, CPU, and storage.

Directory structure: Resource use varies with directory nesting depth and how files are distributed across shares and volumes. Deeply nested or highly fragmented structures can require more resources than the same file count in a flatter hierarchy.

Required scan throughput: Initial catalog completion speed is tied directly to CPU and memory allocation. Provisioning below the recommended size reduces throughput and extends the initial scan window.

Storage performance: High-performance storage is strongly recommended. Metadata indexing and event processing require sustained IOPS and throughput proportional to the deployment size.

Extended initial catalog duration: Reduced compute lowers objects scanned per day. For example, a deployment targeting 3 billion objects but provisioned at a smaller size can take significantly longer than the three to four day target.

Reduced ongoing ingest throughput: New file events and incremental scan updates process more slowly under sustained load.

Storage capacity risk: Undersized storage relative to total object count can push the metadata index toward capacity thresholds. You can typically resolve this by expanding storage capacity, without a full redeployment.

Increase vCPU, memory, or storage on the host VM.

No cluster reconfiguration or reinstallation is required.

AIDE Lite doesn't support high availability or horizontal scale-out. If your environment consistently exceeds 3 billion files, or you require high availability and fault tolerance, deploy AIDE Enterprise instead.

Total file and directory count: Total object count is the dominant driver of storage and compute requirements. Larger environments require additional cluster nodes to distribute processing load and maintain performance.

High availability replication: Enterprise deployments enable data replication across nodes by default for fault tolerance. Replication increases total storage and memory requirements compared to an equivalent single-node deployment.

Node count and workload distribution: Processing throughput and total catalog capacity scale with the number of nodes in the cluster. Additional nodes distribute both the indexing workload and storage capacity across the cluster.

Required scan throughput: Cluster-wide CPU and memory allocation governs the daily scan rate and how quickly the initial catalog completes.

Per-node storage performance: High-performance storage is strongly recommended on each node, and total cluster capacity scales proportionally with node count.

Extended initial catalog duration: Fewer nodes or reduced per-node resources lower throughput, extending the initial catalog window proportionally.

Increased processing latency under peak load: Insufficient memory across the cluster can cause elevated processing latency during high-volume ingestion periods. Ongoing operations are not interrupted, but sustained throughput is reduced.

Storage capacity risk: Insufficient cluster storage for the target object count can push the metadata index toward capacity thresholds. You can resolve this by expanding storage on existing nodes (non-disruptive) or adding a dedicated storage node.

Add worker nodes to increase the CPU and memory available for scan processing and event ingestion.

Add dedicated storage nodes to increase total catalog capacity. This is the primary way to scale environments beyond the largest predefined deployment size.

Scale beyond 6 billion files by adding more nodes to the cluster. Contact your NetApp representative for node sizing guidance at custom scales.

Adding nodes to an existing Enterprise cluster is non-disruptive to ongoing scan operations, but coordinate the change during a low-activity window.