Elasticsearch
The full-blown distributed search + analytics engine. Capable, complex, expensive at scale.
VISIT ELASTICSEARCHKey takeaway: Justified at the top of the scale curve and rarely below it. Choose Elasticsearch when the corpus is genuinely large, the aggregations are complex, or search shares a cluster with logs and metrics. For a mid-market product search box it is the wrong shape, and Typesense or Meilisearch reach most of the same outcome without needing a platform team behind them.
Quick facts
- CategoryDatabase-native FTS
- EngineJava
- PricingFreemium
- LicenseAGPL-3.0 (Elastic License after 2024 relicensing)
- Created2010
- GitHub stars70.4k
- Vector supportYes
- Edge-readyNo
What it is
Elasticsearch is the original distributed search engine. Capable of search + analytics + log aggregation + vector search at extreme scale. JVM-based, operationally heavy, real expertise required. The 2024 license shift back to AGPL added open-source clarity but the operational complexity remains.
Best for
- Genuinely massive search workloads (100M+ documents, complex aggregations)
- Apps that need search + log analytics + APM in one engine
- Enterprise deployments with platform-engineering capacity
When not to pick it
Skip Elasticsearch for greenfield mid-market projects, Typesense or Meilisearch deliver 80% of the value with 10% of the operational cost. Skip if your team has no JVM experience.
My take
Elastic is the right answer at the very top of the scale curve. For most teams it is overkill; the operational tax is real and persistent.
What the operational tax actually buys
You are not paying for full-text matching. Every engine in this directory does that. You are paying for the aggregation framework, which handles nested facets, cardinality estimates, date histograms and percentile rollups that lighter engines either cannot express or answer slowly. You are paying for shard-level control, index lifecycle management that ages data through hot, warm and cold tiers, cross-cluster replication, snapshot and restore, and the ability to serve search, log analytics and application traces from one store. You are paying for a query DSL deep enough to encode almost any relevance requirement, and for the fact that enough people have hit your exact problem that the answer is findable. The tax is real and permanent: heap tuning, shard sizing decisions that are awkward to reverse, rolling upgrades, and a cluster that fails in ways requiring someone who genuinely understands it.
Licensing history and how it should affect your decision
Elastic left Apache 2.0 in 2021 for source-available terms, which is the reason OpenSearch exists at all, and in 2024 it added AGPL-3.0 as a further option alongside the Elastic License. The practical position now is that you can self-host under an OSI-approved licence again, which removed the main reason teams defected in the first place. Two things still deserve attention before you architect around it. First, AGPL copyleft has reach that some legal departments will not sign off on, so get that answered early rather than during procurement. Second, the client libraries and the managed offerings sit under their own terms, and Elastic Cloud pricing is a separate conversation from the licence entirely. If your organisation is AWS-committed or needs strict Apache 2.0, OpenSearch answers both without a legal review. Otherwise Elasticsearch remains the more central project with the larger ecosystem.
Frequently asked questions
Is Elasticsearch open source?
Yes, with a caveat worth knowing. Elastic left Apache 2.0 in 2021 for source-available terms, then added AGPL-3.0 as an option in 2024, so self-hosting under an OSI-approved licence is possible again. AGPL copyleft is stricter than Apache 2.0 and some legal teams refuse it outright. If you specifically need Apache 2.0, OpenSearch is the fork that never left it.
Elasticsearch or Typesense?
Typesense for anything that is recognisably a search box: product search, site search, document search under a few hundred million records. Elasticsearch when you need deep aggregations, tiered data lifecycle, or search sharing infrastructure with log analytics. The deciding question is whether you have people who can operate a JVM cluster. If not, that answers it.
Do I need Elasticsearch for a site search box?
Almost certainly not. A site search box is exactly the workload where the operational cost is hardest to justify, since none of the aggregation depth or tiered storage gets used. Pagefind covers static sites, Postgres full-text search covers apps already on Postgres, and Typesense or Meilisearch cover everything in between at a fraction of the effort.
Links
Compare Elasticsearch side-by-side
Similar tools you should also consider
If Elasticsearch is your pick, the next conversation is short
The 30-min call is where your search choice becomes a real architecture, a relevance-tuning plan, and a price range you can take to your stakeholders.