Elasticsearch vs Algolia and Meilisearch for production

By day 65, you've built search logic, tuned relevance, and understood the query DSL. Now comes a production decision that affects your entire system: which search engine do you actually deploy? Elasticsearch vs Algolia and Meilisearch for production isn't about theoretical strengths—it's about control, cost, and how much operational overhead you can absorb.

When you need hosted simplicity: Algolia

Algolia is a hosted search platform built for teams who want search to work immediately. You send data to Algolia's API, configure a few relevance settings in their dashboard, and your frontend connects via their JavaScript client. There's no infrastructure to manage, no cluster to scale, no backups to coordinate.

The pricing model is per-operation: you pay for indexing operations, search queries, and storage. For a typical e-commerce site running 100,000 searches per month and indexing product updates hourly, you're looking at $300–800 monthly depending on your data volume. It scales smoothly—you don't suddenly spike costs when traffic doubles.

A real scenario: your team has just shipped a marketplace frontend and needs faceted search over 50,000 products. You create an Algolia index, push your product catalog via their API, and within a day users see instant, typo-tolerant search results. Algolia handles geo-proximity queries, synonym management, and A/B testing directly in their platform. You deploy a simple search widget and move on.

Here's what a basic push to Algolia looks like:

{
  "requests": [
    {
      "action": "updateObject",
      "body": {
        "objectID": "product-123",
        "name": "Wireless Headphones",
        "price": 149.99,
        "category": "Electronics",
        "inStock": true,
        "description": "Premium over-ear headphones with noise cancellation"
      }
    }
  ]
}

The downside: you're locked into Algolia's pricing model and feature set. If your search needs become very specific—custom tokenization, complex nested aggregations, or domain-specific ranking—you'll hit Algolia's constraints. You also can't audit or modify their ranking algorithms directly.

Lightweight self-hosting: Meilisearch and Typesense

Meilisearch and Typesense sit between Algolia and Elasticsearch on the spectrum. Both are open-source, single-binary deployments that prioritize simplicity over the full feature breadth of Elasticsearch. You run them on your own infrastructure—a single server, Kubernetes, or a managed platform like Railway or Render.

Meilisearch is particularly popular for its zero-configuration setup. You start the binary, push data via JSON API, and search works. Relevance tuning is minimal; the engine handles typos, synonyms, and phonetic matching out of the box. For small to medium datasets (under 10 million documents), Meilisearch feels effortless.

Typesense is similar but offers more control. It supports dynamic faceting, vector search, and multi-field geo-proximity. Both engines store their index in memory with disk persistence, so they're not suitable for massive datasets, but for datasets under 50 GB they're genuinely simple to operate.

A practical example: you're building an internal SaaS tool that searches across 2 million customer records. You deploy Meilisearch to a small VM, configure basic relevance settings, and your backend pushes new records as they're created. The entire search infrastructure costs you $20/month in compute, and you own the data completely.

Indexing data into Meilisearch is straightforward:

POST /indexes/customers/documents
[
  {
    "id": "cust-456",
    "name": "Acme Corp",
    "email": "contact@acme.com",
    "industry": "Manufacturing",
    "annualRevenue": 2500000,
    "createdAt": "2024-01-15"
  }
]

The tradeoff: Meilisearch and Typesense don't scale to the multi-billion-document territory that Elasticsearch handles. They also have simpler aggregation capabilities and less flexibility in custom scoring. For teams operating at Elasticsearch scale, these engines will feel constrained.

Maximum control and power: Elasticsearch

Elasticsearch is the industry standard for production search and analytics at scale. It's a distributed, horizontally scalable search engine built on Lucene. When you need to search billions of documents, implement complex relevance rules, run full-text search alongside structured queries, or operate a multi-tenant platform, Elasticsearch is where you land.

The operational burden is real. You manage shards, replicas, refresh intervals, and garbage collection. You tune JVM settings. You monitor disk I/O and heap usage. You handle cluster upgrades. If something goes wrong at 2 AM, you're on call.

But the flexibility is unmatched. You control tokenization at character level. You write custom scoring functions using script parameters. You combine bool queries, filters, aggregations, and vector similarity in ways that Algolia simply doesn't expose. You can inspect exactly why a document ranked the way it did using the explain API.

Elasticsearch shines in scenarios like these:

• A job board with millions of listings searched by hundreds of thousands of users, where you need complex filters (location radius, salary range, experience level, visa sponsorship) combined with full-text relevance.
• A fintech platform where you index trading data, news feeds, and market signals, then correlate them with custom scoring logic tied to your domain models.
• A content platform (SaaS docs, help center, community forum) where you need semantic search, synonym management, and usage analytics across millions of documents.

A real indexing strategy for Elasticsearch might look like this:

PUT /jobs
{
  "settings": {
    "number_of_shards": 3,
    "number_of_replicas": 1,
    "index.refresh_interval": "30s"
  },
  "mappings": {
    "properties": {
      "title": {
        "type": "text",
        "analyzer": "standard",
        "fields": {
          "keyword": {
            "type": "keyword"
          }
        }
      },
      "description": {
        "type": "text",
        "analyzer": "english"
      },
      "location": {
        "type": "geo_point"
      },
      "salary_min": {
        "type": "integer"
      },
      "salary_max": {
        "type": "integer"
      },
      "company_id": {
        "type": "keyword"
      }
    }
  }
}

A query combining text search, geographic proximity, and numeric range filtering:

GET /jobs/_search
{
  "query": {
    "bool": {
      "must": [
        {
          "multi_match": {
            "query": "python engineer",
            "fields": ["title^2", "description"]
          }
        }
      ],
      "filter": [
        {
          "geo_distance": {
            "distance": "50km",
            "location": {
              "lat": 40.7128,
              "lon": -74.0060
            }
          }
        },
        {
          "range": {
            "salary_min": {
              "lte": 150000
            }
          }
        }
      ]
    }
  },
  "aggs": {
    "companies": {
      "terms": {
        "field": "company_id",
        "size": 10
      }
    }
  }
}

The cost model is different. You either use Elastic Cloud (their managed service, starting ~$100/month for small production clusters) or self-host on your infrastructure. At scale, your primary cost is compute and storage, not per-query pricing.

Making the choice: control and budget

The decision tree is clearer than it first appears:

Choose Algolia if: You have a simple, bounded dataset (under 100 million records), you want zero operational overhead, and your relevance needs are standard (typo tolerance, synonyms, basic ranking). Your product ships fast, and you're willing to pay per operation.

Choose Meilisearch or Typesense if: You want to own your data, you can run your own infrastructure, your dataset is medium-sized (under 50 GB), and you prefer simplicity over customization. You're cost-conscious and don't want complex operational management.

Choose Elasticsearch if: You're building a platform or product where search is core to user experience, your data is large or will grow large, you need deep customization of relevance, or you're already running a microservices infrastructure where adding Elasticsearch fits naturally. You have the operational bandwidth to manage a distributed system.

Common mistakes

• Starting with Elasticsearch for a MVP: New teams often choose Elasticsearch because it's well-known, then spend weeks tuning JVM settings instead of shipping. Start with Algolia or Meilisearch, migrate to Elasticsearch when you have specific needs that justify the operational cost.
• Underestimating Algolia's constraints: Teams build sophisticated custom ranking logic that Algolia doesn't support, then realize they need to migrate. Prototype your ranking requirements before committing to Algolia.
• Not planning for scale: Meilisearch works beautifully at 10 million documents. At 500 million, you'll migrate. Design your data flow to make migration possible; don't couple your application tightly to the search engine API.
• Ignoring operational costs: Elasticsearch is cheaper per query at scale, but more expensive in engineering time. Factor in on-call rotations, monitoring, and cluster management when calculating true cost.
• Picking based on popularity alone: Just because Elasticsearch dominates in the market doesn't mean it's right for your problem. Evaluate against your actual constraints: data volume, team size, search complexity.

Key takeaways

• Algolia is the fastest path to production search if you can accept vendor lock-in and per-operation pricing.
• Meilisearch and Typesense provide the sweet spot for teams who want control and simplicity, without Elasticsearch's operational overhead.
• Elasticsearch is the only choice when you need horizontal scalability, deep relevance control, or complex search logic tied to your domain.
• The real cost isn't the software—it's engineering time and on-call burden. Choose based on your team's capacity and your problem's actual complexity.
• Design your search abstraction layer so you can migrate between engines as your product scales, rather than locking yourself in.