Typesense vs Elasticsearch Costs for WhatsApp Product Search

Building a search feature for a WhatsApp chatbot feels simple until you load 50,000 products into a database. Most developers start with basic SQL LIKE queries. They quickly realize that database performance crawls under the weight of high-volume traffic. When a user sends a message like "red running shoes size 10," they expect a reply in under two seconds. If your search engine takes one second to think, you have already lost half your window for the webhook response.

I spent three weeks migrating a client from a sluggish Elasticsearch setup to Typesense. The goal was to reduce monthly infrastructure bills without sacrificing the sub-millisecond search speed required for a fluid WhatsApp conversation. This article documents the engineering trade-offs and the financial reality of running these two engines at scale.

The WhatsApp Catalog Search Problem

WhatsApp search is different from web search. Users are often on mobile data with high latency. They type with thumbs, leading to frequent typos. They expect the bot to understand intent without complex filters. To meet these expectations, your search engine must support typo tolerance, prefix search, and fast ranking.

Elasticsearch is the industry standard. It is flexible and scales to petabytes of data. But it is a resource hog. Typesense is a newer alternative designed specifically for lightning-fast, in-memory search. For a WhatsApp bot, the primary cost is not storage space but RAM and CPU cycles spent processing text.

Prerequisites for High-Volume Search

Before choosing an engine, ensure you have these components ready:

1. A Clean Product Schema: Your items need unique IDs, titles, descriptions, prices, and image URLs.
2. Messaging Layer: An API to send and receive messages. Developers often use WASenderApi for its simple session-based approach or the Meta Business API for official compliance.
3. Webhook Handler: A server to process incoming messages and trigger search queries.
4. Hosting Environment: A VPS or cloud provider with at least 2GB of RAM for the leanest search setups.

Infrastructure Comparison: RAM is the Price Label

Elasticsearch runs on the Java Virtual Machine (JVM). This requires a significant memory overhead. Even with a small dataset, Elasticsearch needs a heap size of at least 1GB to run reliably. In a production environment with 100,000 products, you will likely need 4GB to 8GB of RAM to prevent Out of Memory (OOM) crashes during heavy indexing or complex aggregations.

Typesense is written in C++. It stores the entire search index in RAM. While this sounds expensive, Typesense is much more efficient with that memory. A 100,000-product index that consumes 2GB of RAM in Elasticsearch might only take 400MB in Typesense. Because Typesense is a single binary, it lacks the JVM overhead. You run it on cheaper, smaller instances.

For a self-hosted setup on a provider like DigitalOcean or Hetzner, the cost difference looks like this:

• Elasticsearch: Needs a $24/month instance for stable performance with medium catalogs.
• Typesense: Runs comfortably on a $6/month instance for the same catalog size.

Implementing Typesense for WhatsApp Search

To start, you must define a collection. This is equivalent to an index in Elasticsearch. You define which fields are searchable and which are used for filtering.

const Typesense = require('typesense');

let client = new Typesense.Client({
  'nodes': [{
    'host': 'localhost',
    'port': '8108',
    'protocol': 'http'
  }],
  'apiKey': 'xyz-123-api-key',
  'connectionTimeoutSeconds': 2
});

const schema = {
  'name': 'products',
  'fields': [
    { 'name': 'title', 'type': 'string' },
    { 'name': 'category', 'type': 'string', 'facet': true },
    { 'name': 'price', 'type': 'float' },
    { 'name': 'in_stock', 'type': 'bool' }
  ],
  'default_sorting_field': 'price'
};

client.collections().create(schema);

Once the collection exists, you index your products. When a message arrives via your WhatsApp webhook, you parse the text and query Typesense.

Handling WhatsApp Search Queries

When a user sends a query, you want to return the most relevant items. Typesense allows you to weight fields. For example, a match in the title is more important than a match in the description. This is vital for WhatsApp where users only see the first few results.

async function searchProducts(queryText) {
  const searchParameters = {
    'q': queryText,
    'query_by': 'title, category',
    'filter_by': 'in_stock: true',
    'per_page': 3
  };

  const results = await client.collections('products').documents().search(searchParameters);
  return results.hits.map(hit => ({
    title: hit.document.title,
    price: hit.document.price
  }));
}

Your webhook then formats these results into a WhatsApp list message or a series of cards. Using WASenderApi, you send these back to the user session. The response time from Typesense is typically 10ms to 50ms. This leaves plenty of time for your messaging API to deliver the reply before the user gets impatient.

Practical Example: The JSON Search Payload

A typical search result from the engine contains metadata that helps you debug relevance. Here is what a successful response looks like when searching for "black coffee":

{
  "facet_counts": [],
  "found": 12,
  "hits": [
    {
      "document": {
        "id": "101",
        "title": "Dark Roast Black Coffee",
        "price": 15.99,
        "category": "Beverages",
        "in_stock": true
      },
      "highlights": [
        {
          "field": "title",
          "matched_tokens": ["Black", "Coffee"],
          "snippet": "<mark>Dark</mark> Roast <mark>Black</mark> <mark>Coffee</mark>"
        }
      ],
      "text_match": 576460752303423500
    }
  ],
  "request_params": {
    "collection_name": "products",
    "per_page": 1,
    "q": "black coffee"
  },
  "search_time_ms": 4
}

Edge Cases and WhatsApp Limitations

WhatsApp has strict character limits and UI constraints. You must handle these edge cases to avoid breaking the user experience:

• Empty Results: If no products match, provide a fallback. Offer a list of popular categories instead of a blank message.
• Broad Queries: A user might type "shoes." If you have 500 shoes, don't send 500 messages. Return the top 3 and a button to "See More" via a website link.
• Typo Tolerance: People often type "shos" instead of "shoes." Both Elasticsearch and Typesense handle this, but you need to tune the "num_typos" parameter in Typesense to ensure accuracy without returning irrelevant noise.
• Synonyms: Set up a synonym list for common variations. If someone searches for "sneakers," they should also see results for "trainers."

Troubleshooting Performance Issues

If your search starts slowing down, check these common bottlenecks:

1. Network Latency: Hosting your search engine in a different region than your webhook handler adds 100ms+ to every request. Keep them in the same data center.
2. Indexing Spikes: Large bulk updates to your catalog can spike CPU usage. Schedule these during low-traffic hours or use a separate indexing node.
3. Memory Swapping: If Typesense or Elasticsearch runs out of physical RAM, the OS starts using the disk (swap). Performance will drop by 90%. Always monitor RAM usage and set alerts.
4. Connection Pooling: Opening a new TCP connection for every search is slow. Use persistent connections or a client library that supports pooling.

FAQ: Search Infrastructure for Chatbots

Is Typesense better than Algolia for WhatsApp bots? Algolia is a managed service with a per-search cost. For high-volume bots, Algolia becomes extremely expensive. Typesense offers similar performance for a flat infrastructure cost. Typesense is better if you want to control your budget.

Should I use Meilisearch instead? Meilisearch is another great option. It is easier to set up than Elasticsearch. However, Meilisearch consumes more RAM than Typesense for large datasets. It also lacks some of the high-availability features found in Typesense clusters.

Can I run these search engines on a shared hosting plan? No. Search engines require dedicated resources. Shared hosting plans will kill your process the moment it starts consuming RAM. Use a VPS or a managed search cloud.

Does Elasticsearch support more languages than Typesense? Elasticsearch has more plugins for specialized linguistic analysis. If your bot needs to support complex Asian languages with custom tokenization, Elasticsearch is often the safer choice. For most European and Latin American languages, Typesense works perfectly.

How do I handle real-time inventory updates? Both engines support instant updates. When a product goes out of stock in your database, send a partial update to the search engine. This ensures users never see "Add to Cart" for items they cannot buy.

Conclusion and Next Steps

Infrastructure costs for a WhatsApp chatbot scale with your catalog and your user base. Elasticsearch provides the most features but carries a heavy tax in RAM and maintenance. Typesense offers a leaner, faster path for product search that significantly lowers the monthly bill on small to medium VPS instances.

If you are starting a new project, deploy Typesense. It is easier to manage and the performance is perfect for the sub-second requirements of a messaging app. For those using an unofficial messaging route like WASenderApi, the low latency of Typesense ensures you stay within the execution limits of your webhook handlers. Your next step is to clean your product data and run your first benchmark on a small $6 server. You will likely see that you don't need the complexity of a massive search cluster to provide a world-class shopping experience on WhatsApp.