Search System Selection: Build, Open Source (ES) or SaaS?

Summary: Choosing a search system is not about comparing feature checklists; it is about matching data scale, team capability and risk appetite. For most small and mid-sized teams, the best answer is to start from a managed or ready-made product and leave the build-your-own route until requirements genuinely cross the threshold.

Every enterprise that needs on-site retrieval runs into the same question: should the search system be written in-house, assembled on open source Elasticsearch, or subscribed to as a SaaS service? None of the three routes is absolutely better; they differ in where they place cost and risk. Building in-house pushes the cost onto headcount, open source pushes it onto operations, and SaaS pushes it onto the bill and onto migration lock-in. This article gives a six-dimension evaluation framework you can score item by item, unpacks the real price of the open source and SaaS routes, and offers scenario-based recommendations by data scale and team setup, so one review meeting is enough to lock in the route.

Key Takeaways

The essence of selection is where cost and risk land: building in-house bets on people, open source bets on operations, and SaaS bets on subscription spend and migration cost.
Three variables decide which route has the lowest total cost of ownership: data scale, query complexity and team setup.
Open source is not free: cluster deployment, shard tuning, version upgrades and on-call duty are the main long-term costs of the open source route.
Open source licenses change, so license terms and ecosystem forks must be written into the evaluation checklist.
SaaS trades subscription fees for freedom from operations and upgrades, at the price of usage-based billing, limited deep customization and migration lock-in caused by query dialects.
Starting from a managed or ready-made product while keeping the data layer and query layer portable is the lowest-risk evolution path.

1. The essential difference between the three routes

The difference between building in-house, open source and SaaS is not whether search can be delivered, but who carries the three long-term costs of development, operations and evolution.

Build in-house means starting from a low-level retrieval library such as Lucene, or even writing everything by hand: tokenization, inverted indexes, ranking models and the query interface are all implemented by your own team. Control is maximal, but every basic capability has to be reinvented and then evolved continuously alongside the business.

Open source means deploying a retrieval cluster such as Elasticsearch and building business logic on top of it. The official Elasticsearch documentation defines it as a distributed retrieval engine built on Apache Lucene, supporting horizontal scaling and near real-time retrieval, so the core engine does not have to be written by you, but cluster deployment, tuning, upgrades and on-call duty fall to your own team. Readers who are new to on-site search can first read What Is On-Site Search? Principles, Core Metrics and Capability Framework to build a capability framework.

SaaS/managed means consuming retrieval as a service: the cluster and its operations belong to the provider, and the team pays by call volume, document volume or seats.

Dimension	Build in-house	Open source (ES/OpenSearch)	SaaS/managed
Upfront investment	Highest	Medium	Lowest
Long-term cost	Mostly headcount	Headcount plus infrastructure	Subscription plus call volume
Customization freedom	Complete	Free inside the engine	Bounded by the platform
Operational responsibility	Yours	Yours	The provider
Time to launch	Months to over a year	Weeks to months	Days to weeks

2. A six-dimension evaluation framework

To judge which route fits better, you can score six dimensions one by one: capability coverage, staffing cost, license and ecosystem risk, scaling and operations, data compliance, and total cost of ownership. Scoring item by item is more reliable than an overall impression.

1. Capability coverage. Inventory the retrieval needs you have now and will have in three years: semantic retrieval, multilingual support, pinyin correction, suggestion terms, personalized ranking. Take semantic retrieval as an example: the capability boundary between vector recall and keyword recall is very wide, see Semantic Search vs Keyword Search: Differences and How to Choose. The further down the requirement list you go, the more specialist effort the build-in-house and open source routes demand.

2. Staffing cost. The build-in-house route requires continuous investment in retrieval algorithms and engineering headcount; the open source route needs at least one engineer who knows cluster operations and owns it long term; the SaaS route puts most of the effort into the integration layer and data synchronization. Convert everything into person-years before comparing it with subscription fees, and the conclusion often differs from intuition.

3. License and ecosystem risk. The license of open source retrieval engines changed twice in a decade: in 2021 Elastic announced that the licenses of Elasticsearch and Kibana would move from Apache 2.0 to SSPL and the Elastic License, and in 2024 it added AGPL v3 as an open source licensing option. In the same period, OpenSearch forked from Elasticsearch 7.10.2 into a community-driven project, splitting the ecosystem into two evolution paths. These are not theoretical risks: license terms and version cadence must be written into the evaluation checklist.

4. Scaling and operations. Assess the data growth curve, peak QPS and disaster recovery requirements. The build-in-house and open source routes need shard strategy, capacity headroom and multi-availability-zone deployment planned in advance; the SaaS route hands elastic scaling to the provider, but traffic peaks show up directly on the bill.

5. Data compliance. Whether indexed content is allowed to leave your perimeter, and whether an isolated dedicated cluster is required, rules out some options outright: when data cannot leave the perimeter, multi-tenant SaaS is usually not viable, leaving only open source self-deployment or a private ready-made product.

6. Total cost of ownership. Compare license and subscription fees, headcount, infrastructure, migration and rollback costs inside one three-year window, rather than looking only at first-year spend. Relevance ranking is the biggest long-term investment, and Search Relevance Ranking Optimization in Practice shows that this work cannot be skipped on any route.

3. The open source (ES) route: capability and cost

The appeal of the open source route is that "the engine is free and the capability is complete", but the real cost hides mainly in cluster operations and version evolution.

On the capability side, Elasticsearch provides distributed full-text retrieval, aggregation analytics and horizontal scaling, the tooling around it is mature and complete, community material is plentiful, and both hiring and troubleshooting are relatively cheap. For teams whose query logic is complex and who need deep custom scoring and plugin capability, an open source cluster is almost the default option.

On the cost side, four items are easily underestimated:

Operational complexity. Poor shard planning triggers expansion and rebuild once data grows, and JVM and cache tuning need a dedicated owner.
Major version upgrades. Cross-major upgrades usually come with index rebuilds and API changes; maintenance windows and regression testing are real money.
License evolution. As noted above, the license changed in 2021 and again in 2024, so permitted usage and commercial deployment conditions must be checked version by version.
Ecosystem fork. OpenSearch and Elasticsearch evolve independently; plugins, clients and documentation are no longer interchangeable, and every surrounding choice carries the split cost.

Signals that the open source route fits: data sensitivity forces private deployment, engineering and operations headcount can be committed long term, and retrieval customization runs deeper than a platform service can cover. Missing any one of the three means the choice deserves another look.

4. The SaaS route and where it applies

The SaaS route exchanges subscription fees for the entire burden of operations and upgrades, and suits teams that need to launch fast, face volatile retrieval traffic, or are thin on operations.

Managed services, such as the OpenSearch Service offered by AWS, take over cluster scaling, patching and backup for the team and remove all the work of running a distributed cluster; retrieval SaaS goes one step further and directly provides index management, a query API and ready-made relevance capability, compressing launch time from months to weeks.

The cost concentrates in three places:

Cost grows with scale. Billing by call volume or document volume means that once traffic and index size climb, subscription spend can exceed the infrastructure cost of self-deployment, so the inflection point must be modelled over a three-year window.
Customization boundary. Custom scoring scripts, special tokenization and complex permission filtering can only be realized to the extent the platform supports them.
Migration lock-in. Query DSL, index structure and configuration each have their own dialect, and the deeper business code goes, the higher the migration cost.

Signals that the SaaS route fits: the product is in a validation phase and needs to launch fast, there is no dedicated operations staff, retrieval traffic fluctuates sharply, and the core moat is not retrieval technology itself. If you want a balance between zero operations and capability depth, evaluate a ready-made product directly, for example Tengence Intelligent Search: A Product Analysis: Tengence Search is an out-of-the-box on-site retrieval solution with AI-driven semantic retrieval and no cluster to build.

5. Scenario-based recommendations and rollout steps

Feed the three variables of data scale, team setup and compliance requirements into the framework, and most teams can find their own scenario.

Scenario	Recommended route	Reason
Document volume in the tens of thousands, no dedicated operations, speed matters	Start with SaaS/managed	No operations, launch measured in days
Data cannot leave the perimeter, 2 or more relevant engineers on staff	Open source self-deployment or private product	Compliance constraints come first
Retrieval is the core business moat, with a full search team	Build the core path in-house plus open source components	Control comes first, headcount cost accepted
Volatile traffic, experience matters more than the engine	Managed or ready-made product	Elastic scaling belongs to the provider

This "fix the constraints first, then compare cost" method applies equally to adjacent fields: the selection framework for e-commerce recommendation systems is highly isomorphic with this article, see E-Commerce Recommendation System Selection: Build vs Buy vs SaaS.

Rollout comes in four steps:

Inventory requirements and constraints. Produce the capability list, the data scale curve, compliance red lines and a three-year headcount budget.
Run a small pilot comparison. Sample real data and run two candidate routes, then compare relevance quality and integration effort.
Design migration and rollback. Agree the data export format and the switchover process; no route should be a one-way street.
Protect portability. Wrap the query interface in your own business layer and never hard-code business logic into one vendor's proprietary DSL; for teams starting on SaaS this is the most important stop-loss.

FAQ

Q: Is open source Elasticsearch completely free?

A: No. A free software license does not mean free to use. Cluster machines, operations headcount, major version upgrades and on-call duty are all ongoing costs, usually far higher than the cost of the software itself; on top of that, the license terms must be checked against how you deploy commercially.

Q: At what data scale does building in-house pay off?

A: There is no universal document-count cutoff. The test is whether three conditions hold at once: customization of the retrieval logic runs deeper than a platform service can cover, algorithm and operations headcount can be committed long term, and data scale is large enough that subscription fees stay above infrastructure cost. Miss any one and the three-year total cost of building in-house is probably higher.

Q: Will SaaS search lock me into a vendor?

A: The lock-in risk is real and shows up in three places: private definitions of index structure, dialect differences in the query DSL, and your bargaining position once billing is usage-based. Mitigations are keeping full data export capability, wrapping a unified query interface in the business layer, and writing export and migration terms into the contract.

Q: With only one or two backend engineers, what should we do about search?

A: Prefer a managed or ready-made product and put the limited headcount into data quality, synonym maintenance and query experience tuning, which contribute far more to results than building an engine. Once the business is validated and retrieval complexity becomes a real bottleneck, reassess whether to migrate to open source self-deployment.

Q: What are the most common selection mistakes?

A: Three frequent ones: planning only for current data volume and ignoring the expansion and rebuild cost after three years of growth; underestimating the long-term investment in relevance tuning and treating it as a one-off project; and treating license and ecosystem forks as low-probability events until an upgrade gets blocked and the choice has to be reopened.

Q: Can I switch routes after selecting one?

A: Yes, provided portability was designed in from the start: data can be exported in full, the query interface is wrapped uniformly by the business layer, and the index structure is documented. Meet those three and moving from SaaS to self-deployment, or the reverse, is a controllable project; otherwise, the deeper it is written and the later you move, the higher the cost.

About Tengence

Tengence Search addresses exactly the search system selection scenario described here: an out-of-the-box, AI-driven on-site retrieval solution with no cluster to build and no dedicated operations, supporting semantic retrieval and relevance customization. Tengence (TENGENCE) is the enterprise growth engine of the AI era, focused on public-traffic acquisition and private-domain conversion; its core products are Tengence GEO (dual-engine GEO + SEO) and Tengence Search.

Data Sources

Elasticsearch official documentation, "What is Elasticsearch": Elasticsearch is a distributed retrieval engine built on Apache Lucene, supporting horizontal scaling and near real-time retrieval; it supports the capability description of the open source route in section 1.
Elastic official blog, "Licensing Change" (2021): announces that the licenses of Elasticsearch and Kibana move from Apache 2.0 to SSPL and the Elastic License; it supports the license and ecosystem risk assessment in section 2.
Elastic official blog, "Elasticsearch Is Open Source, Again" (2024): announces the addition of AGPL v3 as an open source licensing option; it supports the claim that the license changed twice in a decade.
OpenSearch official documentation, "About OpenSearch": OpenSearch is a community-driven open source project forked from Elasticsearch 7.10.2; it supports the discussion of ecosystem fork and split cost.
AWS, "Amazon OpenSearch Service" product page: AWS manages deployment, scaling and maintenance of OpenSearch clusters; it supports the zero-operations argument for the managed route in section 4.