On-Premise eDiscovery Benchmarks: Speed & Scale

On-Premise eDiscovery Performance Benchmarks: Processing Speed, Concurrent Users, and Storage Scaling

Most organizations that run on-premise eDiscovery do not know where their platform breaks until it already has. A surge in litigation volume, a regulatory inquiry with tight deadlines, or a cross-border investigation that demands simultaneous review by distributed teams, these are the scenarios that expose the gap between what a system was configured to handle and what it is being asked to do today.

Performance benchmarks exist precisely to close that gap. Yet in practice, many legal and compliance teams select or inherit an on-premise eDiscovery platform based on vendor-supplied figures that reflect ideal conditions, not production environments under real organizational load. The result is a system that performs well in demonstrations and underperforms when it matters most.

Why Benchmarks Matter More Than Specs

A vendor specification tells you what a system can do under controlled conditions. A benchmark tells you what it does under yours. Those two numbers are rarely the same.

According to ComplexDiscovery's 2025 eDiscovery Processing Update, processing speed, concurrent user capacity, and storage architecture are the three operational variables that most directly affect case timelines and per-matter cost. Organizations that measure these variables against their own workload profiles make better infrastructure decisions and avoid emergency remediation mid-matter.

The three benchmarks every organization should evaluate before committing to an on-premise eDiscovery platform are:

• Data processing throughput (GB/hour under full production load)

• Concurrent user capacity without measurable performance degradation

• Storage scaling behavior as repository size grows

Processing Speed: The First Bottleneck in Every Matter

Processing speed determines when review can begin. Every hour of processing delay is an hour of review capacity lost. For matters with compressed response deadlines, processing throughput is not a technical detail — it is a case management variable.

The EDRM's 2025 Processing Benchmark found that speed varies by 2.5x between the fastest and slowest platforms on the market. A platform processing at 85 GB/hour can ingest a 500 GB collection in under six hours. A platform processing at 38 GB/hour requires nearly thirteen hours for the same dataset — a full business day of difference that compresses downstream review time and increases risk of missed deadlines.

What to Measure

When benchmarking processing speed on an on-premise installation, measure:

• Throughput at 25%, 50%, 75%, and 100% of expected peak load

• Throughput when processing is concurrent with active review sessions

• Degradation rate as file type diversity increases (native files, email containers, structured data)

• Recovery behavior after a processing failure or queue restart

Most on-premise platforms publish single-threaded benchmark numbers. In production environments, processing rarely runs in isolation. A realistic test accounts for concurrent workloads.

Concurrent User Capacity: Where On-Premise Deployments Most Often Fail

Concurrent user load is the most common source of unexpected performance failures in on-premise discovery management software. A platform that performs well with ten simultaneous reviewers may degrade noticeably at thirty and become unusable at fifty, particularly during peak review periods when the entire team is active at once.

The challenge is structural. On-premise platforms allocate fixed compute resources. When user demand spikes, those resources are shared, and response times increase. Unlike cloud-native architectures that can provision additional compute on demand, on-premise systems require manual intervention: hardware upgrades, configuration adjustments, or review session throttling.

Defining Your Concurrent User Threshold

Before selecting or evaluating an on-premise platform, define:

• Peak concurrent internal users during active review phases

• Expected outside counsel user counts and access patterns

• Whether concurrent processing activity coincides with peak review

• Acceptable response time thresholds for search, coding, and document loading

Testing should simulate real concurrent behavior, not sequential logins. A vendor demonstration with one or two active users does not reflect the load profile of a large-scale review.

As noted in Reveal's analysis of on-premise eDiscovery scaling gaps, adding outside counsel reviewers to a traditional on-premise platform requires license modifications, IT provisioning, and often VPN configuration. In matters where outside counsel need to be productive quickly, that overhead directly delays review start.

Storage Scaling: The Long-Term Architecture Question

Storage scaling affects both the cost structure and the operational resilience of an on-premise deployment. As data volumes grow — and they will, given the continued expansion of collaboration platforms, cloud applications, and structured data sources, the storage architecture must scale without degrading search and retrieval performance.

The most common failure mode is not running out of storage space. It is storage architecture that cannot maintain query performance as the repository grows. A legal team accustomed to sub-second search responses on a 500 GB repository may encounter multi-second delays on the same queries at 5 TB, not because of hardware limits, but because the index structure was not designed for that scale.

Key Storage Architecture Considerations

• Index architecture: Does search performance degrade linearly, logarithmically, or precipitously as repository size grows?

• Tiered storage support: Can inactive matters be moved to lower-cost storage without removing them from the index?

• Multi-matter isolation: Does storage growth in one matter affect retrieval performance in others?

• Backup and recovery architecture: How long does a full restore take at 10 TB versus 1 TB?

The IDC MarketScape: Worldwide End-to-End eDiscovery Software 2025 notes that legacy on-premise platforms are approaching end-of-life cycles by 2028. For organizations that have not yet evaluated whether their storage architecture can support the next five years of data growth, that window is narrowing.

The Deployment Architecture Factor

Benchmark results are only as meaningful as the deployment architecture they reflect. The same software running on different hardware configurations, network topologies, or virtualization layers can produce benchmark results that differ by 30 to 50 percent.

This is one reason why private deployment architectures deserve attention alongside traditional on-premise installations. A private deployment, software running on dedicated infrastructure in a private cloud or managed data center, can deliver the data control requirements of an on-premise model while enabling more flexible compute allocation, eliminating the hardware procurement cycle, and supporting faster capacity adjustments when workload demands shift.

The choice between traditional on-premise installation and private deployment is not purely technical. It involves organizational considerations around IT resource availability, capital versus operating expenditure preferences, and the flexibility needed to respond to litigation surges. Both models can be appropriate. What matters is that the deployment architecture is matched to the organization's actual performance requirements and growth trajectory, as explored in Reveal's analysis of flexible eDiscovery deployment as a competitive advantage.

How to Conduct a Meaningful Performance Evaluation

A rigorous performance evaluation for best eDiscovery software selection or renewal goes beyond vendor-provided benchmarks. The following framework provides a practical starting point.

Step 1: Define Your Load Profile

Document your typical and peak workloads:

• Average and maximum data volumes per matter

• Peak concurrent users across internal staff and outside counsel

• Number of active matters running simultaneously

• Expected data growth rate over the next three years

Step 2: Run Tests That Match Real Conditions

• Test processing throughput with concurrent review activity running

• Simulate peak user loads using realistic review workflows, not idle sessions

• Run storage scaling tests at 2x and 5x your current repository size

• Measure search response times at each scale increment

Step 3: Evaluate the Gaps Against Your Requirements

The goal is not to find a platform with no performance limits — all systems have limits. The goal is to find a platform whose limits are outside the range of your expected workloads, with sufficient headroom to absorb spikes without degradation.

If benchmark testing reveals gaps between current performance and operational requirements, those gaps have defined solutions: hardware upgrades, architectural changes, or a transition to a private deployment model that offers more flexible capacity management.

Performance Is a Strategy, Not a Specification

Legal and compliance teams that treat on-premise eDiscovery performance as a pure IT concern are accepting more risk than they realize. When a platform cannot process data fast enough, review timelines slip. When concurrent user loads exceed capacity, reviewers lose productivity during the exact period when speed matters most. When storage scaling degrades search performance, the entire matter suffers.

Performance benchmarks are the mechanism for translating those risks into specific, measurable requirements, and for holding vendors accountable to them. Organizations that invest the time to benchmark their current or prospective platforms against their actual load profiles make better deployment decisions, reduce per-matter costs, and build legal operations infrastructure that can support the next three to five years of demand, not just today's.

Ready to benchmark your on-premise eDiscovery deployment against your actual workload? Reveal's team works with legal operations and IT leaders to evaluate platform performance against organizational requirements and identify where the architecture needs to change before the matter does. Talk to our team.