When your app or website needs real search (typo tolerance, relevance ranking, filters, facets, instant results), three self-hosted engines dominate. Elasticsearch (and its open-source fork OpenSearch) is the powerful, general-purpose giant. Meilisearch and Typesense are lightweight engines focused on instant, user-facing search. Here’s how they compare.

Quick comparison

Elasticsearch / OpenSearch Meilisearch Typesense
Best for Complex search, analytics, logs, large clusters Instant site and app search, minimal setup Instant search with built-in HA
Setup and tuning Significant (mappings, analyzers, JVM, cluster) Minimal, good defaults Minimal, explicit schema
Typo tolerance out of the box Configurable (fuzzy queries) Yes, automatic Yes, automatic
Query language Very rich JSON DSL, aggregations Simple search parameters, filters, facets Simple parameters, filters, facets
Analytics and aggregations Excellent Basic facets Basic facets
Log and observability use Industry standard (ELK / OpenSearch Dashboards) Not designed for it Not designed for it
Memory footprint (small dataset) 1–2 GB+ minimum (JVM heap) Small Index in RAM, proportional to data
Clustering Mature, sharding and replication Single node (open source) Built-in Raft cluster
Vector / hybrid search Yes Yes Yes
Licence Elastic: AGPL/SSPL/ELv2. OpenSearch: Apache 2.0 MIT GPLv3

Elasticsearch / OpenSearch

Strengths:

  • Extremely flexible: custom analyzers for any language, complex boolean queries, scoring functions, nested documents.
  • Aggregations for analytics dashboards: counts, histograms and statistics over billions of records.
  • The de facto standard for log analytics (with Logstash or Beats and Kibana, or OpenSearch Dashboards).
  • Scales horizontally to huge clusters.

Costs:

  • Operational complexity: heap sizing, shard planning, mappings, upgrades and cluster health.
  • Resource hungry: a production node wants 4–8 GB of RAM or more, and small VPSes struggle.
  • Relevance for “search as you type” needs tuning (fuzziness, edge n-grams).

See install Elasticsearch and install OpenSearch.

Meilisearch

Strengths:

  • A single binary, running in minutes, with excellent default relevance and typo tolerance.
  • Great developer experience, SDKs, and integrations like Laravel Scout.
  • Low resource use for typical site-search datasets.

Limits:

  • Not built for analytics or logs.
  • High availability isn’t part of the open-source edition. Run a standby and re-index, or use the cloud offering.
  • Very large datasets need care during indexing (CPU and memory).

See install Meilisearch.

Typesense

Strengths:

  • Very fast (in-memory index), typo-tolerant, with facets and filters.
  • Built-in clustering with Raft for high availability.
  • Scoped API keys for multi-tenant search.

Limits:

  • RAM proportional to the indexed data.
  • Explicit schemas mean a bit more upfront work (also a benefit).
  • Not for analytics or logs.

See install Typesense.

Which should you choose?

Use case Recommendation
E-commerce product search, docs search, site search Meilisearch or Typesense
Search with built-in high availability Typesense (or Elasticsearch/OpenSearch)
Log management and observability OpenSearch or Elasticsearch (or Grafana Loki for logs only)
Analytics dashboards with aggregations Elasticsearch / OpenSearch
Complex, multi-language, custom relevance Elasticsearch / OpenSearch
Small VPS (2–4 GB RAM), simple search Meilisearch or Typesense
You already run PostgreSQL and the search is simple PostgreSQL full-text search (tsvector) first

Don’t forget the database you already have

PostgreSQL’s full-text search (to_tsvector, GIN indexes, pg_trgm for fuzzy matching) and MySQL’s FULLTEXT indexes handle many small and medium needs, with no extra service to run, back up or keep in sync. Add a dedicated engine when you need typo tolerance, facets at speed, or better relevance. See database indexing.

Keeping search in sync

Whatever engine you pick, your primary database stays the source of truth:

  • push updates from the application (on save and delete), or via queues;
  • schedule a full re-index periodically to correct drift;
  • version index settings in code, so you can rebuild from scratch.

Sizing on a VPS

Engine Small dataset (<1M docs) Notes
Elasticsearch/OpenSearch 4–8 GB RAM, 2+ vCPU Heap ≤ 50% of RAM. Fast SSD
Meilisearch 1–4 GB RAM More RAM = faster. Indexing is CPU-heavy
Typesense ~2–3× the indexed data size in RAM Cluster of 3 for HA

See how much RAM a VPS needs.

Related: SQL vs NoSQL and vector databases.

  • Search
  • Databases
  • Self-Hosting