Performance
Exaba’s performance is an envelope you size to the workload, not a fixed appliance figure. It decomposes into three primitives — throughput, latency, and operation rate — each gated by different hardware. Knowing which one your workload needs is what turns a target into a build. Exaba sizes each deployment with you; this page explains the levers.
Throughput — the baseline
Throughput is the aggregate GB/s the cluster moves, and it is the primitive most deployments size for.
- The data path is NVMe-oF over RDMA, delivering 10+ GB/s of object throughput per node.
- Compute (C) and storage (D) layers scale independently, so aggregate throughput grows linearly as nodes are added.
- Throughput is gated by the network and node count, not the data-drive media. Writes are acknowledged from the NVMe staging area, so HDD data drives sustain full ingest given enough spindles, and HDDs handle large sequential reads (restore windows) well.
To reach the top of the throughput envelope: an RDMA fabric (RoCEv2 or iWARP; TCP is supported for sites without RDMA), high-bandwidth bonded NICs (25–200 GbE), NVMe metadata drives, and enough nodes to hit the aggregate target.
Latency optimisation
Latency is time-to-first-byte per operation, and it splits by direction:
- Write latency is bounded by the NVMe staging area, so with adequate staging headroom it is independent of the data-drive media — HDD and NVMe data drives acknowledge writes equally fast.
- Read latency depends on the data-drive media. This is where NVMe data drives earn their place: latency-sensitive reads — hot tier, transactional, AI/ML — benefit from NVMe, while bulk and sequential reads do not.
Add NVMe data drives when read latency is the constraint; otherwise HDD data with NVMe metadata is the better-value choice.
Operation rate (small objects, high GET/s)
Small-object and metadata-heavy workloads are bound by operations per second rather than raw bandwidth, and the lever depends on the operation. High GET/s of small objects is limited by data-drive random-read IOPS, where NVMe data drives far outperform HDD; this is the primary case for NVMe data. Metadata-heavy operations (LIST, HEAD, indexing) are driven by NVMe metadata drives.
Capacity and cost
For archive and long-term retention, the target is cost per TB, not speed: bulk HDD data with NVMe metadata gives the lowest cost per TB with modest networking. This is the standard backup and retention configuration and trades peak read latency for capacity.
Sizing
Align the hardware to the primitive your workload needs — a throughput figure, a latency or restore-time objective, or a cost per TB. See the Compatibility Matrix for validated fabrics and reference platforms, and Hardware Sizing for the sizing process.