Elastic Enterprise Search pricing: Elasticsearch enterprise search cost and Elastic Workplace Search migration

There is no published price, because Elastic does not sell Elastic Enterprise Search anymore. Existing 8.x subscribers pay whatever their current Elastic subscription costs. Everyone else is pricing the replacement, which is Elasticsearch billed by consumption rather than by user.

On Elastic Serverless Search, these are the rates Elastic publishes, read on September 15, 2026. Elastic labels each one "as low as", so treat them as floors rather than the number you will pay.

Elastic also publishes two worked examples, which are more useful than the rate card because they show what the meters add up to. A development environment with 2 GB of searchable data, 1 percent ingest utilization (15 minutes a day) and 8 percent search utilization (2 hours a day) comes to $24 a month on the On-demand setting and $27 on Performant. A production environment with 20 GB of searchable data, 5 percent ingest utilization (1 hour a day) and 33 percent search utilization (8 hours a day) comes to $190 a month On-demand and $210 Performant. Performant is the default.

Twenty gigabytes is the number to sit with. A mid-sized company's Slack history, Drive, Confluence and ticket system together are usually far past that, and search utilization for a tool the whole company uses is not 8 hours a day on one node. Elastic's examples are honest illustrations of the pricing mechanics, not a forecast for a company-wide search deployment.

No. Elastic states plainly that Enterprise Search "will no longer be available in Elastic version 9.0 and beyond", and that new Elastic customers who subscribed after the 9.0 release do not have access to these products. If you already hold an Enterprise Search subscription, you can continue to use Enterprise Search 8.x, including App Search and Workplace Search.

That single sentence changes the shape of the decision. This is not a case of an aging product that is still purchasable while a newer one matures. The door is closed. Any team evaluating Elastic Workplace Search today because a colleague used it at a previous job is evaluating something they cannot sign for.

Swiftype is worth a line here too, because the names are tangled. Elastic acquired Swiftype, and App Search and Workplace Search grew out of it. Elastic's end-of-life table lists Swiftype.com Site Search as a retired SaaS product with no maintenance or support dates attached. If your search for "swiftype elastic" brought you here, the short version is that the whole family landed in the same place.

Elastic's end-of-life table gives three dates for Elastic Enterprise Search 8.x: a Software Product Retirement Notice Date of April 15, 2025, End of Maintenance on January 15, 2027, and End of Support on July 15, 2027.

The date that governs planning is End of Maintenance, not End of Support, and it is the one most roadmaps get wrong. After January 15, 2027 the software still runs, but nobody is patching it. For a system that holds an index of internal documents with permissions attached, running unpatched is a conversation with your security team, not a technicality. Count backwards from that date: a replatform that touches connectors, permissions and every application embedding search is rarely a one-quarter project.

There is also a quieter trap. Enterprise Search is gone from 9.0, so a routine stack upgrade for unrelated reasons removes it. Teams running Elasticsearch for logs and Workplace Search for internal search are effectively frozen on 8.x across both until the search side is replaced.

Elastic's migration guidance replaces four things, and none of them is a version bump. Workplace Search content sources become Elasticsearch indices fed by self-managed connectors you host. App Search engines become Elasticsearch indices queried directly. The Elastic Web Crawler becomes Open Crawler. Elastic managed connectors become self-managed connectors.

Written out as work, that list is longer than it looks:

• Connector hosting. Managed connectors ran as part of the product. Self-managed connectors are services you deploy, monitor, patch and keep authenticated against every source system.
• The relevance layer. App Search gave you tunable relevance, synonyms and curations through an interface. Against raw Elasticsearch, that becomes query DSL somebody owns and maintains.
• Document-level permissions. This is the part that quietly consumes the schedule. Every source has its own model, and each has to be mapped into index filters and re-checked as group membership changes.
• The interface. Workplace Search shipped a search experience for employees. Elasticsearch ships an API.
• Crawled content. The Web Crawler becomes Open Crawler, which is a separate component with its own configuration and operational story.

None of this is a criticism of Elasticsearch, which is an excellent search engine and the foundation of a great deal of production software. It is a statement about scope. A team that budgets an Elastic migration as an infrastructure line item and then discovers it has committed to building and operating an internal search product is the common failure here. Price the engineering time next to the alternative of buying a finished one, and the comparison becomes honest in both directions.

Elasticsearch is the search and analytics engine. Elastic Enterprise Search was a set of finished products built on top of it: App Search for search inside your own application, and Workplace Search for search across company tools such as Google Drive, Salesforce, Confluence and Dropbox. The engine continues and is actively developed. The finished products on top were retired.

This distinction is the single biggest source of confusion in the results you get for these queries, and most published comparison articles miss it. Roundups titled around Elasticsearch alternatives compare it to OpenSearch, Solr, Meilisearch and Typesense, which are all search engines. If you are replacing Workplace Search, none of those answer your question either, because your problem was never the engine. It was connectors, permissions and an answer layer over company content, and those are exactly the parts that were removed.

So the honest framing when you evaluate replacements: either you are rebuilding a search product on an engine, in which case Elasticsearch or OpenSearch is a reasonable foundation and the cost is engineering time, or you are buying a finished one, in which case the comparison set is the workplace search vendors, not the search engines.

They come from review sites and pricing roundups, not from Elastic. TrustRadius lists Elastic Enterprise Search with plans starting around $79, and several guides quote roughly $95 to $99 a month for a small Elastic Cloud Hosted production configuration. Elastic's own pricing pages publish consumption rates and deployment-size calculators, not packaged plan prices at those figures.

We are flagging this rather than repeating it because a number in a budget needs a source that will still be correct next quarter. The figures are not necessarily wrong as historical snapshots of somebody's deployment. They are simply not Elastic list prices, and quoting them as such is how procurement conversations go sideways.

If you need a defensible Elastic number, the route is Elastic's own pricing calculator with your real data volume and query load, not a third-party plan table. And if you are pricing the retired product specifically, there is no correct figure to find, because it is not for sale.

If your job is log analytics, observability, security analytics or search inside a product you are building, Elastic is an excellent choice and this page should not talk you out of it. The consumption model is a genuine advantage when volume is predictable and engineering capacity exists, because you pay for what you index and query rather than for every employee who might run a search.

The place the model stops fitting is company-wide internal search. There, the work is not indexing, it is the long tail of connectors, each source's permission model, and keeping all of it current while people join, leave and change teams. That work does not get cheaper with a better engine, which is precisely why Elastic built Workplace Search in the first place and why its removal leaves a real gap.

InSearch fills that gap as a finished product. Google Drive, Slack, Notion, Confluence, Gmail, Jira and Salesforce connect once, centrally, and each source's own permissions are enforced per person at query time, so nobody sees a snippet from a document they could not already open. Answers come back cited to the source document, which is what makes them usable in a decision. It is priced per seat, so the budget is a number rather than a forecast. If you are staring at January 15, 2027 and weighing a rebuild against a purchase, that is the comparison worth running, and it is fair to run it with real engineering hours on the Elastic side rather than infrastructure cost alone.