Relativity: what the platform is, and why its pricing is never published

Relativity is an enterprise eDiscovery and legal-data platform used across the discovery lifecycle. Its pricing page does not publish a price figure or a pricing unit; it directs prospective buyers to talk with sales. The page was checked in November 2026, and current pricing and capability should be verified with the vendor because these pages change.

This page is not a review, and no Relativity product or feature was tested. It provides a factual orientation to the platform, its published pricing model, the deployment questions suggested by its own materials, and the matter profiles for which an enterprise platform may be worth evaluating.

What Relativity is at the platform level#

Relativity operates at the enterprise end of eDiscovery. The category includes platforms that support legal teams and litigation-support functions as data moves through collection, processing, review, analysis, production, and closeout. That is a functional description of the category, not a claim about every workflow or configuration available from the vendor.

The pricing materials reference a cloud platform and, separately, a server policy applicable alongside the cloud platform. The materials also identify a FedRAMP-certified option for government work. Those references matter when assessing deployment because a cloud arrangement, a server environment, and a government-specific option involve different procurement, security, and administration questions.

An enterprise platform may also appear in a broader legal-data workflow rather than only in a traditional lawsuit. The relevant question is therefore not simply whether the software handles document review. It is whether the platform fits the organization’s approach to data across the discovery lifecycle, including the controls surrounding that data and the arrangements required when the matter ends.

Product naming is in flux#

The pricing page is titled for Relativity aiR. The site presents what was known as RelativityOne under that name. That naming transition is important for anyone comparing documentation, contracts, training materials, support resources, or third-party summaries.

Current product names should be checked in Relativity’s present documentation rather than inferred from an older article, a reseller page, a search result, or another secondary source. A page that accurately described RelativityOne when written may no longer describe the current naming structure accurately.

The same caution applies to feature labels. A familiar term may remain in use within a matter team while the vendor’s public materials use a different product or interface name. Any evaluation should begin with a current account of the proposed environment, including the platform name, deployment model, contractual entity, support path, and relevant administrative documentation.

How the pricing page handles pricing#

Relativity’s pricing page publishes neither a price figure nor a pricing unit. Its call to action is to talk to sales. There is consequently no published amount to quote and no public unit such as per user, per gigabyte, or per document on which to calculate a comparison from the page itself.

A November 2026 check of the pricing pages for Everlaw, Relativity, Logikcull, DISCO, and Nextpoint produced the same central result: none of those pages publishes a price figure, and every one routes the prospective buyer to a sales conversation. The pages are not directly comparable as published price lists because they do not publish comparable figures or units.

That does not establish that Relativity is more expensive, less expensive, or differently priced than another platform. It establishes only what the public pages disclose. A meaningful cost comparison requires a written proposal tied to a defined matter profile, data scope, user population, deployment pattern, support requirements, and contractual term.

Because the vendor’s pricing page changes, current pricing and capability should be verified directly with Relativity. Older quotations, screenshots, budget assumptions, and third-party pricing summaries may describe a different package, product name, or commercial structure.

Why an enterprise platform is quoted rather than listed#

A list price works best when the seller can define the billable unit and the buyer can predict the quantity. For an enterprise eDiscovery platform, the variables may include the volume and variety of data, the number of custodians, review populations, hosting arrangements, configuration, support, security requirements, integrations, and the duration of the matter.

Matter profiles can differ enough that a single published number would not provide a reliable basis for planning. Two matters involving the same legal issue may present different data, review, production, and administration requirements. A direct quotation tied to a defined profile can therefore be more useful than an abstract rate that may not apply to the actual matter.

This explanation concerns the practical difficulty of standardizing a quote; it does not describe undisclosed commercial arrangements. No conclusion should be drawn from this page about reseller terms, partner arrangements, discount practices, or negotiated discounts. Those points require a proposal and direct confirmation from the vendor.

Cloud, server, and government deployment#

The public materials establish three deployment references that deserve separate treatment in any evaluation: a cloud platform, a separate server policy alongside that cloud platform, and a FedRAMP-certified option for government work. The materials do not turn those references into a universal statement that every deployment is available for every matter.

For cloud evaluation, the questions are likely to include data location, administrator control, user access, support boundaries, and the process for handling data after the engagement. For a server deployment, procurement may need the server policy and the technical documentation governing the environment rather than the cloud materials alone.

Government work may raise a distinct set of requirements around authorization status, procurement vehicles, security documentation, records handling, and contract terms. The stated FedRAMP-certified option should be confirmed for the particular offering and matter. Certification status, covered services, and agency authorization can be specific matters of verification rather than blanket conclusions for every use of the platform.

Evaluation questions for an enterprise eDiscovery platform#

The useful comparison is not the presence of a feature name. It is whether the platform’s operating model matches the matter and the organization’s controls. Five dimensions are especially important when assessing Relativity alongside other enterprise platforms: ingestion breadth, auditability of the technology-assisted review workflow, production flexibility, administration, and export on exit.

These are questions for a demonstration and written proposal, not findings about Relativity. The appropriate answer may vary by product configuration, contract, hosting model, matter, and service arrangement. The platform-choosing guide provides the broader method for conducting that comparison without treating any single vendor as the answer.

Ingestion breadth#

Ask what data sources can enter the environment, which formats are supported, how metadata is preserved, and how exceptions are reported. The discussion should connect source families to the actual matter profile. A source that does not exist in the matter adds little to a requirements list, while a foreseeable source may affect both processing decisions and the schedule for review.

Auditability of the TAR workflow#

Technology-assisted review raises workflow questions beyond whether the platform offers predictive coding. Ask how decisions are logged, who can administer them, how training and validation are documented, and how an activity record can be retrieved. The auditability question is about traceability through the workflow, not a claim about the accuracy of any result.

Production flexibility#

Production requirements may involve document families, metadata fields, redactions, load files, confidentiality designations, or delivery formats. Ask which combinations are supported, which controls are administrative, and how changes are documented. A production discussion should use the anticipated specifications rather than a generic sample.

Administration#

Determine who controls users, permissions, matter structure, retention, and access to matters that may contain privileged or regulated information. Also ask where those administrative responsibilities sit between the legal team, litigation support, and information technology. A clear product division does not necessarily produce a clear operating model for the organization using it.

Export on exit#

Ask what can leave the platform at the end of a matter, in what formats, and under what conditions. Include native files, processed content, metadata, review records, audit logs, and any matter-specific configuration. The exit discussion is more useful when it covers both ordinary production and the transfer or deletion of working data after the engagement.

Who should evaluate an enterprise platform#

An enterprise platform tends to suit matter profiles in which the complexity of the data, review population, organizational controls, or reporting requirements justifies a dedicated enterprise operating model. That can include large custodians, repeated document families, sensitive data, multi-party work, or a legal team coordinating review across several matters. Government work may also justify close examination of the stated FedRAMP-certified option.

Matter profile also includes organizational profile. Large legal teams may have the administrators, security reviewers, and support resources needed to manage a broad platform. A smaller team can still require enterprise capabilities because of regulation, data sensitivity, or a complex dispute, but the control requirements will not disappear merely because the team is small.

The platform should be evaluated against the operating burden it introduces. That burden may include administration, training, configuration, governance, contracting, and the need to integrate with existing systems. The relevant question is not whether an enterprise platform is categorically more capable, but whether those capabilities correspond to needs that are present in the matter.

The counterpoint for a small matter#

An enterprise platform can be the wrong tool for a small, straightforward matter. If the data is limited, the review population is narrow, production requirements are familiar, and the organization already has a workable process, the expense and administration of an enterprise deployment may not be justified.

The opposite conclusion is equally unwarranted. A matter that begins with limited data can develop additional custodians, disputed production specifications, or governance requirements. Scaling decisions should be tied to the matter as it is actually scoped, while preserving a clear record of any assumptions used in the estimate.

For a smaller matter, a written quote from Relativity can still be compared with other enterprise options or narrower tools. The comparison should account for total operating effort rather than just the quoted amount. A lower subscription figure, for example, would not establish a lower cost if setup, administration, or data handling differs materially.

What to request before comparing proposals#

A useful sales conversation should begin with a written matter profile rather than a request for a generic rate. Include the anticipated data sources and volume, custodian and user populations, review workflow, production specifications, hosting model, security requirements, administrative ownership, and expected duration. Mark known uncertainties instead of allowing assumptions to remain implicit.

Ask Relativity to confirm the proposed product name, deployment path, pricing unit, included services, support responsibilities, and contract terms in writing. If the discussion involves government work, request the documentation relevant to the stated certified option. If server deployment is under consideration, obtain the current server policy and related technical materials.

The evaluation should then test the same questions across each candidate: ingestion breadth, TAR auditability, production flexibility, administration, and export. A table organized by those dimensions is more useful than a list of features because it exposes differences in workflow and control rather than merely differences in terminology.

Finally, separate proposal terms from public-page observations. The pricing page does not publish a figure or unit, and the sales conversation will not substitute for the written proposal. Current pricing and capability should be verified with the vendor because both the pages and the available configurations change.

The practical takeaway#

Relativity is an enterprise eDiscovery and legal-data platform with cloud, server-policy, and government-option references on its public pricing materials. The page checked in November 2026 provides no price figure and no pricing unit; it routes buyers to sales.

That fact does not supply a cost comparison, but it identifies where the comparison must occur: in a proposal tied to a defined matter and in a structured evaluation of operational requirements. The pricing page is not a review, no product was tested, and current pricing and capability should be verified directly with the vendor.