Elasticsearch

PostgreSQL full-text search is sufficient when your dataset is under 5–10 million rows, your search queries are simple keyword lookups with basic ranking, and you want to avoid adding another infrastructure component. It handles basic tsvector/tsquery operations well and supports GIN indexes for reasonable performance. Elasticsearch becomes necessary when you need advanced relevance tuning (field boosting, function scoring, decay functions), when your users expect typo tolerance and "did you mean" suggestions, when you need faceted navigation with real-time filter counts, or when your dataset exceeds tens of millions of documents. Elasticsearch also excels at multi-language search with per-language analyzers, autocomplete with completion suggesters, and near-real-time indexing for fresh content. For e-commerce product search — where typo tolerance, synonym expansion, and faceted filters are table stakes — Elasticsearch is the industry standard. The operational overhead of running an Elasticsearch cluster (JVM tuning, shard management, capacity planning) is the trade-off, which is why we only recommend it when PostgreSQL's search capabilities are genuinely insufficient.

Elasticsearch scales horizontally by distributing data across shards, which are allocated to nodes in the cluster. Each index is divided into primary shards (which handle writes) and replica shards (which serve reads and provide fault tolerance). Adding nodes to the cluster triggers automatic shard rebalancing, increasing both storage capacity and query throughput without downtime. For high availability, we configure at least three master-eligible nodes to prevent split-brain scenarios, place nodes across multiple availability zones (or physical racks), and set replica counts so that the cluster can lose an entire zone without data loss. Shard sizing is critical: we target 20–40 GB per shard as a sweet spot for query performance and recovery speed. Index Lifecycle Management (ILM) policies automatically roll over time-series indices, move cold data to cheaper storage tiers, and delete expired data. Cross-cluster replication enables disaster recovery across regions. In production, we have operated clusters with 50+ nodes serving 500+ queries per second across billions of documents with p99 latency under 200ms.

Elasticsearch production costs depend heavily on data volume, query complexity, and availability requirements. A three-node cluster on AWS (r6g.xlarge instances with 4 vCPUs, 32 GB RAM, and gp3 EBS volumes) suitable for 50–200 million documents costs approximately $1,200–$2,000/month. Elastic Cloud (the managed service from Elastic) starts around $200/month for small workloads and scales to $5,000–$15,000/month for high-traffic production clusters with multiple availability zones. The biggest cost drivers are memory (Elasticsearch is JVM-based and benefits from large heaps, up to 30 GB), storage I/O (especially for write-heavy logging workloads), and replica count (each replica doubles storage requirements). For logging and observability use cases, Elastic's newer serverless offering charges per ingested and searched data volume rather than per node, which can be more cost-effective for variable workloads. OpenSearch (the AWS fork) is a viable alternative that reduces licensing costs for organizations that do not need Elastic's proprietary ML and security features.

Typesense and Meilisearch are lightweight search engines designed for simplicity and developer experience, while Elasticsearch is a full-featured distributed search and analytics platform. Typesense is written in C++ and delivers instant search with typo tolerance out of the box — it requires zero configuration for basic use cases, consumes far less memory than Elasticsearch, and is ideal for small-to-medium datasets (under 100 million documents) where operational simplicity matters. Meilisearch offers a similar developer-friendly experience with RESTful APIs and excellent documentation. Elasticsearch's advantages are scale (billions of documents across distributed clusters), analytics capabilities (aggregations, pipeline processing, Kibana visualization), the breadth of its query DSL, and its ecosystem for logging and observability (ELK stack). For a startup building product search with under 10 million items, Typesense or Meilisearch will get you to production faster with less operational burden. For enterprise search spanning multiple data sources, log analytics, and complex relevance engineering, Elasticsearch remains the industry standard.

The Elasticsearch ecosystem in 2026 is split between Elastic's commercial offerings and the open-source OpenSearch fork maintained by AWS. Elastic has refocused on its "Elastic Search AI Platform" vision, integrating vector search for semantic queries, ELSER (Elastic Learned Sparse Encoder) for hybrid search relevance, and retrieval-augmented generation (RAG) workflows that combine traditional BM25 ranking with vector embeddings. Elasticsearch 8.x introduced kNN vector search natively, making it a viable alternative to dedicated vector databases for many use cases. Kibana remains the primary visualization and management tool, with Lens dashboards, Canvas for custom presentations, and Elastic Observability for APM and infrastructure monitoring. On the alternative side, OpenSearch 2.x has kept pace with most Elasticsearch features and added its own ML capabilities and dashboard tools. The broader search ecosystem includes Vespa (from Yahoo, strong for recommendation), Qdrant and Weaviate (vector-native databases), and the aforementioned Typesense and Meilisearch for simpler use cases. Client libraries exist for every major language, and the Elasticsearch Python client is especially popular in data engineering and ML pipelines.