Meilisearch vs Elasticsearch

Agent ops

1. ai-native userMy coding agent can create an index, add documents, and run queries end to end — through the API, CLI, or MCP without touching a dashboard

   weight 3 · round drawn
   Meilisearch✓fullprobed8/10

   Meilisearch provides a full REST API, official SDKs/CLI-style tooling, and a documented official MCP server that explicitly supports creating indexes, adding documents, configuring settings, and performing searches via natural-language prompts — enabling an agent to do the whole workflow without a dashboard. This is corroborated by a dedicated MCP integration page and probe confirming its existence. Missing for 10: independent/hands-on validation of the MCP server specifically (community evidence covers API/self-hosting but not MCP end-to-end), and no explicit standalone CLI tool for index/document CRUD beyond the API.

   • [claimed-docs] “Once configured, you can create indexes, add documents, configure settings, and perform searches using natural language prompts.”
   • [claimed-docs] “you can create indexes, add documents, configure settings, and perform searches using natural language prompts”
   • [claimed-docs] “Update ranking rules, searchable attributes, and faceting through natural-language prompts.”
   • [claimed-docs] “Index documents, tune ranking rules, and search Meilisearch through natural conversation in the AI client you already use.”
   • [probe] “official MCP server documented at https://www.meilisearch.com/docs/getting_started/integrations/mcp”
   • [claimed-docs] “Meilisearch is a single binary with no external dependencies. You can run it on any Linux, macOS, or Windows machine, on bare metal or in co…”
   • [claimed-docs] “Typed SDKs for JavaScript, Python, Ruby, PHP, Go, Rust, Java, Swift, Dart, and .NET.”

   proof ↗⚑ flag

   Elasticsearch✓fullprobed8/10

   Elasticsearch exposes a full REST API for index creation, document ingestion, and querying (elastic-docs-4, elastic-docs-19), ships official client libraries (elastic-docs-6), provides an official MCP server (elastic-docs-28, elastic-probe-4) and 'skills' packages that teach coding agents to use the stack (elastic-docs-10) — all without requiring the Kibana dashboard. missing for 10: no dedicated first-party CLI tool distinct from curl/API calls, and no independent hands-on report confirming an agent completing the full create-index→add-docs→query loop via the MCP server.

   • [claimed-docs] “Elasticsearch can combine vector search with full-text search, structured filters, aggregations, and hybrid retrieval in one engine”
   • [claimed-docs] “Elasticsearch functions as a vector database when you store embeddings in `dense_vector` or `sparse_vector` fields and query them for simila…”
   • [claimed-docs] “Elasticsearch is easy to use from most popular programming languages, thanks to the wide range of official libraries and developer tools ava…”
   • [claimed-docs] “elastic / mcp-server-elasticsearch Public”
   • [probe] “official MCP server documented at https://github.com/elastic/mcp-server-elasticsearch”
   • [claimed-docs] “Install official skills that teach AI coding agents how to work with Elasticsearch, Kibana, Fleet, and the rest of the Elastic stack.”
   • [claimed-docs] “All you need to do is create an index mapping to start ingesting, embedding, and querying data. There is no need to define model-related set…”

   proof ↗⚑ flag

2. ai-native userAgents can use my search indexes as a tool — an MCP server or tool-calling surface exposes query, analytics, and index operations

   weight 2 · round to Meilisearch
   Meilisearch✓fullprobed8/10

   Meilisearch documents an official MCP server (integrations/mcp) that lets agents create indexes, add documents, configure settings, update ranking rules/searchable attributes/faceting, and perform searches using natural-language prompts, confirmed independently via probe evidence of the documented integration page. Analytics tracking (queries, clicks, conversions) is also exposed as a core capability, though not explicitly confirmed as callable via the MCP surface itself. Missing for 10: independent/hands-on confirmation of the MCP server in actual agent use, and explicit evidence that analytics endpoints are exposed through the MCP tool-calling surface specifically (vs. just the general API).

   • [claimed-docs] “Once configured, you can create indexes, add documents, configure settings, and perform searches using natural language prompts.”
   • [claimed-docs] “you can create indexes, add documents, configure settings, and perform searches using natural language prompts”
   • [claimed-docs] “Update ranking rules, searchable attributes, and faceting through natural-language prompts.”
   • [claimed-docs] “Index documents, tune ranking rules, and search Meilisearch through natural conversation in the AI client you already use.”
   • [claimed-docs] “Track search queries, click events, and conversions to measure search quality and identify opportunities for improvement.”
   • [claimed-docs] “Meilisearch analytics helps you understand how users interact with your search. Track search queries, click events, and conversions to measu…”
   • [probe] “official MCP server documented at https://www.meilisearch.com/docs/getting_started/integrations/mcp”

   proof ↗⚑ flag

   Elasticsearch✓fullprobed7/10

   Elastic maintains and documents an official MCP server (elastic/mcp-server-elasticsearch) that exposes Elasticsearch to AI agents as a tool-calling surface, plus 'skills' docs for AI coding agents to work with the stack. Missing for 10: detailed documentation of exactly which operations (query, analytics, index management) the MCP server exposes, and independent/hands-on corroboration of its reliability.

   • [claimed-docs] “elastic / mcp-server-elasticsearch Public”
   • [probe] “official MCP server documented at https://github.com/elastic/mcp-server-elasticsearch”
   • [claimed-docs] “Install official skills that teach AI coding agents how to work with Elasticsearch, Kibana, Fleet, and the rest of the Elastic stack.”

   proof ↗⚑ flag

Agent access

1. ai-native userPoint an agent at llms.txt or agent-oriented docs

   weight 2 · round to Meilisearch
   Meilisearch✓fullprobed9/10

   Meilisearch serves an llms.txt at the root (HTTP 200) and provides .md versions of docs pages that explicitly point agents to a documentation index at /docs/llms.txt, confirming agent-oriented doc discovery is actively supported. missing for 10: no independent/community confirmation that agents actually consume these successfully in practice.

   • [probe] “PROBE llms.txt: HTTP 200 at https://www.meilisearch.com/llms.txt # Meilisearch — Official Information (llms.txt) This file is maintained by…”
   • [probe] “PROBE docs-md: HTTP 200 at https://www.meilisearch.com/docs/getting_started/overview.md > ## Documentation Index > Fetch the complete docume…”

   proof ↗⚑ flag

   Elasticsearch~partialprobed3/10

   Elastic explicitly advertises 'official skills that teach AI coding agents how to work with Elasticsearch' (elastic-docs-10) and has an official MCP server (elastic-probe-4/elastic-docs-28), which are agent-oriented resources, but direct probes show no llms.txt or docs.md file exists (elastic-probe-1, elastic-probe-2), so the specific story of pointing an agent at llms.txt is not supported. Missing for 10: a working llms.txt/docs.md endpoint, and any first-party documentation detailing the 'skills' content or how an agent consumes it.

   • [claimed-docs] “Install official skills that teach AI coding agents how to work with Elasticsearch, Kibana, Fleet, and the rest of the Elastic stack.”
   • [probe] “PROBE llms.txt: HTTP 404 at https://www.elastic.co/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://www.elastic.co/docs.md”
   • [probe] “official MCP server documented at https://github.com/elastic/mcp-server-elasticsearch”

   proof ↗⚑ flag

2. ai-native userRun the product headlessly / in CI for automation

   weight 2 · round drawn
   Meilisearch~partialclaimed6/10

   Meilisearch is a single binary/Docker image with official SDKs, cURL-installable, and no external dependencies, making it straightforward to run headlessly in CI/automation pipelines (docs-11, docs-12, docs-18, docs-44, docs-73). However, there is no explicit documentation or examples specifically addressing CI usage, headless test automation, or scripted startup/health-check patterns for pipelines. missing for 10: explicit CI/CD examples or guides, headless-mode automation docs, community evidence of running Meilisearch in CI pipelines.

   • [claimed-docs] “Meilisearch is a single binary with no external dependencies. You can run it on any Linux, macOS, or Windows machine, on bare metal or in co…”
   • [claimed-docs] “Download the latest stable release of Meilisearch with cURL. Launch Meilisearch to start the server.”
   • [claimed-docs] “curl -L https://install.meilisearch.com | sh”
   • [claimed-docs] “Install Meilisearch locally on Linux, macOS, or Windows using cURL, Docker, Homebrew, APT, or from source.”
   • [claimed-docs] “Official Meilisearch Docker images for easy deployment and development.”
   • [claimed-docs] “For production deployments, you will also need: A reverse proxy (Nginx or Caddy) for HTTPS termination A process manager (systemd)... A mast…”

   proof ↗⚑ flag

   Elasticsearch~partialclaimed6/10

   Elasticsearch ships a headless-friendly install path (curl one-liner, Docker quickstart) and REST API plus official clients in multiple languages, which supports scripted/CI automation, but there is no explicit CI/automation guide or documented CLI for pipeline integration in the evidence pack. missing for 10: dedicated CI/automation documentation, examples of running in pipelines, headless configuration flags/env-var setup guidance.

   • [claimed-docs] “curl -fsSL https://elastic.co/start-local | sh”
   • [claimed-docs] “Quickly set up Elasticsearch and Kibana in Docker for local development or testing, using this one-liner in the command line.”
   • [claimed-docs] “Elasticsearch is easy to use from most popular programming languages, thanks to the wide range of official libraries and developer tools ava…”

   proof ↗⚑ flag

3. ai-native userConnect an agent via an official MCP server

   weight 3 · round to Meilisearch
   Meilisearch✓fullprobed8/10

   Meilisearch publishes an official MCP server integration allowing AI agents/clients to create indexes, add documents, configure settings, and search using natural-language prompts, confirmed via docs and a dedicated integrations page and probe. missing for 10: independent/hands-on community verification of the MCP server's real-world reliability.

   • [claimed-docs] “Once configured, you can create indexes, add documents, configure settings, and perform searches using natural language prompts.”
   • [claimed-docs] “you can create indexes, add documents, configure settings, and perform searches using natural language prompts”
   • [claimed-docs] “Update ranking rules, searchable attributes, and faceting through natural-language prompts.”
   • [claimed-docs] “Index documents, tune ranking rules, and search Meilisearch through natural conversation in the AI client you already use.”
   • [probe] “official MCP server documented at https://www.meilisearch.com/docs/getting_started/integrations/mcp”

   proof ↗⚑ flag

   Elasticsearch✓fullprobed7/10

   Elastic maintains an official MCP server repository (elastic/mcp-server-elasticsearch) confirmed both in docs listing and by direct probe, enabling AI agents to connect to Elasticsearch via MCP. Missing for 10: detailed setup/usage documentation for the MCP server and independent hands-on validation of its functionality.

   • [claimed-docs] “elastic / mcp-server-elasticsearch Public”
   • [probe] “official MCP server documented at https://github.com/elastic/mcp-server-elasticsearch”

   proof ↗⚑ flag

4. ai-native userUse an official CLI

   weight 2 · round drawn
   Meilisearch—none0/10

   The evidence pack shows a self-hosted single binary, SDKs, Docker/Kubernetes integrations, and an official MCP server for natural-language interaction, but there is no mention of a dedicated official CLI tool for AI-native workflows (e.g., a `meilisearch-cli` package or command-line client distinct from the server binary itself).

   • [claimed-docs] “Meilisearch is a single binary with no external dependencies. You can run it on any Linux, macOS, or Windows machine, on bare metal or in co…”
   • [claimed-docs] “Download the latest stable release of Meilisearch with cURL. Launch Meilisearch to start the server.”
   • [claimed-docs] “Install Meilisearch locally on Linux, macOS, or Windows using cURL, Docker, Homebrew, APT, or from source.”
   • [claimed-docs] “Official Meilisearch Docker images for easy deployment and development.”
   • [claimed-docs] “Once configured, you can create indexes, add documents, configure settings, and perform searches using natural language prompts.”

   proof ↗⚑ flag

   Elasticsearch—none0/10

   The evidence pack mentions official client libraries (elastic-docs-6) and an MCP server (elastic-docs-28), but no official CLI tool tailored for AI-native/agentic workflows is documented anywhere in the pack.

   • [claimed-docs] “Elasticsearch is easy to use from most popular programming languages, thanks to the wide range of official libraries and developer tools ava…”
   • [claimed-docs] “elastic / mcp-server-elasticsearch Public”

   proof ↗⚑ flag

5. ai-native userDrive the product through a documented public API

   weight 3 · round to Meilisearch
   Meilisearch✓fullprobed8/10

   Meilisearch is API-first: full REST API documented for creating indexes, adding documents, searching, and configuring settings, plus typed SDKs for 10+ languages and llms.txt/markdown-doc endpoints explicitly aimed at AI assistants. This gives an AI-native user a clear, documented public API surface to drive the product programmatically. Missing for 10: a discoverable machine-readable OpenAPI/Swagger spec (candidate URLs all returned 404), and independent hands-on confirmation of API completeness beyond vendor docs.

   • [claimed-docs] “creating a project and an index, adding documents to it, and performing your first search with the default web interface”
   • [claimed-docs] “Meilisearch is a single binary with no external dependencies. You can run it on any Linux, macOS, or Windows machine, on bare metal or in co…”
   • [claimed-docs] “Typed SDKs for JavaScript, Python, Ruby, PHP, Go, Rust, Java, Swift, Dart, and .NET.”
   • [claimed-docs] “Integrate powerful search into your mobile and web applications with our easy-to-use APIs and SDKs for every major language.”
   • [claimed-docs] “The official JavaScript client for Meilisearch, with full TypeScript support for Node.js and browser environments.”
   • [claimed-docs] “The official Python client for Meilisearch with async support and type hints.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://www.meilisearch.com/llms.txt # Meilisearch — Official Information (llms.txt) This file is maintained by…”
   • [probe] “PROBE docs-md: HTTP 200 at https://www.meilisearch.com/docs/getting_started/overview.md > ## Documentation Index > Fetch the complete docume…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://www.meilisearch.com/openapi.json, https://www.meilisearch.com/swagger.json, https://www.meil…”

   proof ↗⚑ flag

   Elasticsearch~partialprobed6/10

   Elasticsearch's core interaction model is REST-API-driven, evidenced by client libraries (elastic-docs-6), inference/semantic_text APIs (elastic-docs-9,11,23), and explicit AI-agent enablement via an official MCP server (elastic-docs-28, elastic-probe-4) and 'skills' for coding agents (elastic-docs-10). However, automated probes found no llms.txt, no docs.md, and no discoverable OpenAPI/swagger spec at standard paths (elastic-probe-1,2,3), undercutting machine-readable API discoverability for AI-native tooling. Missing for 10: a verifiable OpenAPI/swagger spec or llms.txt, and independent hands-on evidence of an agent successfully driving the API end-to-end.

   • [claimed-docs] “Elasticsearch is easy to use from most popular programming languages, thanks to the wide range of official libraries and developer tools ava…”
   • [claimed-docs] “The inference API workflow is more complex but offers greater control over the inference endpoint configuration.”
   • [claimed-docs] “Install official skills that teach AI coding agents how to work with Elasticsearch, Kibana, Fleet, and the rest of the Elastic stack.”
   • [claimed-docs] “elastic / mcp-server-elasticsearch Public”
   • [probe] “PROBE llms.txt: HTTP 404 at https://www.elastic.co/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://www.elastic.co/docs.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://www.elastic.co/openapi.json, https://www.elastic.co/swagger.json, https://www.elastic.co/api…”
   • [probe] “official MCP server documented at https://github.com/elastic/mcp-server-elasticsearch”

   proof ↗⚑ flag

6. ai-native userIssue scoped/least-privilege API credentials for an agent

   weight 2 · round to Meilisearch
   Meilisearch✓fullclaimed7/10

   Meilisearch documents tenant tokens as short-lived, scoped API credentials generated from an API key that embed search rules (filters) restricting data visibility per tenant/user — a direct mechanism for least-privilege scoped credentials suitable for an agent. Combined with API keys controlling permissions, this directly enables issuing scoped credentials for an AI agent (e.g. for its MCP integration). Missing for 10: explicit documentation tying tenant tokens/API key scoping specifically to AI agent use cases, and independent/hands-on validation of scoped-token behavior in agentic workflows.

   • [claimed-docs] “Tenant tokens are short-lived, scoped credentials generated from an API key. They embed search rules (filters) that automatically apply to e…”
   • [claimed-docs] “Tenant tokens are short-lived, scoped credentials generated from an API key. They embed search rules (filters) that automatically apply to e…”
   • [claimed-docs] “tenant tokens serve a similar purpose to Algolia's secured API keys or PostgreSQL's row-level security (RLS)”
   • [claimed-docs] “Meilisearch uses API keys and tenant tokens to control access to your data.”
   • [claimed-docs] “API keys authenticate requests, while tenant tokens restrict what data each user can see within a shared index.”
   • [claimed-docs] “Once configured, you can create indexes, add documents, configure settings, and perform searches using natural language prompts.”

   proof ↗⚑ flag

   Elasticsearch—none0/10

   The evidence pack contains no mention of API key scoping, role-based access control, or least-privilege credential issuance for agents/service accounts in Elasticsearch; nothing addresses creating scoped API keys or restricting permissions for AI agent use. This is a plausible and well-known Elasticsearch capability (API keys with role descriptors exist in the product) but is simply absent from the provided evidence, so it must be judged 'none' rather than assumed.

   ⚑ flag

7. ai-native userBuild against official SDKs

   weight 2 · round drawn
   Meilisearch✓fullcommunity8/10

   Meilisearch documents official typed SDKs for JavaScript, Python, Ruby, PHP, Go, Rust, Java, Swift, Dart, and .NET, with dedicated first-party client pages for JS and Python, plus Docker/Kubernetes/Laravel integrations. Community evidence (comm-5) confirms real-world usage of official language clients (e.g., Rails gem) though notes occasional version-compatibility friction. Missing for 10: independent hands-on corroboration for the full SDK matrix beyond JS/Python and no explicit versioning/maintenance cadence details.

   • [claimed-docs] “Typed SDKs for JavaScript, Python, Ruby, PHP, Go, Rust, Java, Swift, Dart, and .NET.”
   • [claimed-docs] “Integrate powerful search into your mobile and web applications with our easy-to-use APIs and SDKs for every major language.”
   • [claimed-docs] “The official JavaScript client for Meilisearch, with full TypeScript support for Node.js and browser environments.”
   • [claimed-docs] “The official Python client for Meilisearch with async support and type hints.”
   • [claimed-docs] “First-party Meilisearch driver for Laravel Scout, the official Laravel search package.”
   • [claimed-docs] “Official Meilisearch Docker images for easy deployment and development.”
   • [community] “The other issue we faced is their Rails gems falling out of step with the server, and when fixes came out, the Rails gem was incompatible fo…”

   proof ↗⚑ flag

   Elasticsearch✓fullprobed8/10

   Elastic documents a wide range of official client libraries covering popular programming languages (elastic-docs-6), giving AI-native developers standard SDKs to build against, complementing official MCP server support for agentic integration (elastic-docs-28, elastic-probe-4). missing for 10: independent hands-on validation of SDK quality/coverage beyond first-party docs, and no explicit mention of language-specific AI/agent framework integrations within the SDKs themselves.

   • [claimed-docs] “Elasticsearch is easy to use from most popular programming languages, thanks to the wide range of official libraries and developer tools ava…”
   • [claimed-docs] “elastic / mcp-server-elasticsearch Public”
   • [probe] “official MCP server documented at https://github.com/elastic/mcp-server-elasticsearch”

   proof ↗⚑ flag

8. ai-native userSubscribe to events via webhooks

   weight 2 · round drawn
   Meilisearch—none0/10

   No evidence in the pack mentions webhooks or event subscription mechanisms; only search, indexing, security, analytics, and MCP integration capabilities are documented. Absence of evidence for this applicable axis (a search engine could plausibly emit indexing/task webhooks) means verdict is none.

   ⚑ flag

   Elasticsearch—none0/10

   Elasticsearch offers watchers/alerting internally but no evidence in the pack shows a webhook subscription mechanism for AI-native agents to receive events; no docs describe outbound webhooks for event subscription.

   ⚑ flag

Agentic features

1. ai-native userGet AI-generated insights and suggestions from my data inside the product

   weight 2 · round drawn
   Meilisearch~partialclaimed4/10

   Meilisearch ships a 'conversational search' product that lets end users ask questions and get answers grounded in indexed data, plus a RAG-focused retrieval product and personalization that adapts results to user behavior — these are AI-generated, data-grounded outputs. However, these are building-block APIs for developers to embed in their own apps rather than an in-product AI insights/suggestions experience for the Meilisearch user themselves, and there is no evidence of a dashboard or admin-facing AI-generated insights feature. Missing for 10: an in-product AI insight/analytics dashboard for the Meilisearch operator, independent evidence of conversational search quality/accuracy, and clarity that this is end-user-facing rather than developer-embedded.

   • [claimed-docs] “Let users ask questions and get real answers, grounded in your own content. No hallucinations, no guessing.”
   • [claimed-docs] “The retrieval layer your AI applications need. Give your models accurate, current context from your own data.”
   • [claimed-docs] “Three users search for "laptop". Each sees results ranked by their unique preferences, no extra configuration needed.”
   • [claimed-docs] “Tailor every search to every user. Surface what is most relevant to each person based on their preferences and behavior.”
   • [claimed-docs] “Once configured, you can create indexes, add documents, configure settings, and perform searches using natural language prompts.”

   proof ↗⚑ flag

   Elasticsearch~partialclaimed4/10

   Elasticsearch documents strong building blocks for AI-driven data work — automatic embedding generation via semantic_text, hybrid/vector search, and explicit support for RAG pipelines (elastic-docs-1, elastic-docs-11, elastic-docs-18, elastic-docs-19) — but these are infrastructure for developers to build their own AI insight layer, not a native in-product feature that surfaces AI-generated insights/suggestions to end users. Missing for 10: evidence of an actual built-in insights/summary/suggestion UI (e.g., Kibana AI Assistant narrative insights) generating analysis automatically, and independent confirmation that end users see such generated insights rather than just raw search results.

   • [claimed-docs] “When you index content into a `semantic_text` field, Elasticsearch automatically generates vector embeddings using a configured machine lear…”
   • [claimed-docs] “When you index content into a `semantic_text` field, Elasticsearch automatically generates vector embeddings using a configured machine lear…”
   • [claimed-docs] “RAG (Retrieval Augmented Generation) systems”
   • [claimed-docs] “Elasticsearch functions as a vector database when you store embeddings in `dense_vector` or `sparse_vector` fields and query them for simila…”
   • [claimed-docs] “All you need to do is create an index mapping to start ingesting, embedding, and querying data. There is no need to define model-related set…”

   proof ↗⚑ flag

2. ai-native userSet up automations that run autonomously in the background

   weight 2 · round drawn
   Meilisearch—none0/10

   Evidence shows Meilisearch offers an MCP integration for interactive natural-language configuration and search (meilisearch-docs-13, meilisearch-docs-57), but nothing describes scheduled jobs, triggers, or autonomous background automations that run without a user driving them. missing for 10: any scheduler/automation engine, background trigger system, or autonomous agent workflow capability.

   • [claimed-docs] “Once configured, you can create indexes, add documents, configure settings, and perform searches using natural language prompts.”
   • [claimed-docs] “Index documents, tune ranking rules, and search Meilisearch through natural conversation in the AI client you already use.”
   • [probe] “official MCP server documented at https://www.meilisearch.com/docs/getting_started/integrations/mcp”

   proof ↗⚑ flag

   Elasticsearch—none0/10

   Elasticsearch is a search/data engine, not an automation/orchestration platform; the evidence covers indexing, vector search, hybrid search, serverless scaling, and an MCP server for connecting agents to ES data, but nothing about scheduling or running autonomous background automations/workflows. No watcher/alerting or agentic automation feature is documented in this pack.

   ⚑ flag

3. ai-native userDelegate tasks to a built-in AI assistant inside the product

   weight 3 · round to Meilisearch
   Meilisearch~partialprobed4/10

   Meilisearch doesn't ship a built-in AI assistant inside its own UI, but it does offer an official MCP server that lets external AI clients (Claude, etc.) index documents, tune settings, and search 'through natural conversation,' effectively delegating admin tasks via natural language. This is delegation via an external AI client connecting to Meilisearch, not an assistant built into the product itself. Missing for 10: an in-product/embedded assistant UI, evidence of task delegation happening natively inside Meilisearch's own interface rather than through a third-party AI client, and independent hands-on confirmation of the MCP workflow.

   • [claimed-docs] “Once configured, you can create indexes, add documents, configure settings, and perform searches using natural language prompts.”
   • [claimed-docs] “you can create indexes, add documents, configure settings, and perform searches using natural language prompts”
   • [claimed-docs] “Update ranking rules, searchable attributes, and faceting through natural-language prompts.”
   • [claimed-docs] “Index documents, tune ranking rules, and search Meilisearch through natural conversation in the AI client you already use.”
   • [probe] “official MCP server documented at https://www.meilisearch.com/docs/getting_started/integrations/mcp”

   proof ↗⚑ flag

   Elasticsearch—none0/10

   The evidence pack shows Elasticsearch's search/vector/RAG capabilities and an external MCP server for connecting AI agents to Elasticsearch, but nothing describes a built-in AI assistant embedded in the product that a user can delegate tasks to. This is a fair capability to expect from a modern data platform (many now ship in-product AI assistants), so absence of evidence means 'none' rather than 'na'.

   • [claimed-docs] “Install official skills that teach AI coding agents how to work with Elasticsearch, Kibana, Fleet, and the rest of the Elastic stack.”
   • [claimed-docs] “elastic / mcp-server-elasticsearch Public”
   • [probe] “official MCP server documented at https://github.com/elastic/mcp-server-elasticsearch”

   proof ↗⚑ flag

4. ai-native userOperate the product with natural-language commands

   weight 2 · round drawn
   Meilisearch~partialprobed6/10

   Meilisearch offers an official MCP server that lets users create indexes, add documents, configure settings, and perform searches via natural-language prompts in an AI client, which is strong first-party evidence of natural-language operability. However this is scoped to an external MCP integration rather than a native NL interface built into the core product, and there's no independent/hands-on corroboration of this specific MCP workflow beyond vendor docs. missing for 10: independent/hands-on validation of the MCP natural-language workflow, evidence of natural-language support outside the MCP integration (e.g., built-in NL query parsing in core API), and detail on reliability/limitations of the NL command interface.

   • [claimed-docs] “Once configured, you can create indexes, add documents, configure settings, and perform searches using natural language prompts.”
   • [claimed-docs] “you can create indexes, add documents, configure settings, and perform searches using natural language prompts”
   • [claimed-docs] “Update ranking rules, searchable attributes, and faceting through natural-language prompts.”
   • [claimed-docs] “Index documents, tune ranking rules, and search Meilisearch through natural conversation in the AI client you already use.”
   • [probe] “official MCP server documented at https://www.meilisearch.com/docs/getting_started/integrations/mcp”

   proof ↗⚑ flag

   Elasticsearch~partialprobed6/10

   Elasticsearch itself is a query/DSL-based search engine, but it ships an official MCP server (elastic/mcp-server-elasticsearch) and documented 'skills' that teach AI coding agents how to operate Elasticsearch, Kibana, and Fleet — enabling natural-language-driven operation via an agent intermediary rather than a native NL interface. Missing for 10: first-party documentation of the MCP server's actual command coverage/reliability, independent hands-on validation of natural-language query results, and any built-in (non-MCP) NL query feature.

   • [claimed-docs] “elastic / mcp-server-elasticsearch Public”
   • [probe] “official MCP server documented at https://github.com/elastic/mcp-server-elasticsearch”
   • [claimed-docs] “Install official skills that teach AI coding agents how to work with Elasticsearch, Kibana, Fleet, and the rest of the Elastic stack.”

   proof ↗⚑ flag

Api quality

1. ai-native userExplore an interactive API reference with runnable examples

   weight 2 · round drawn
   Meilisearch—none0/10

   The evidence pack shows no interactive API reference or runnable-example playground; the openapi probe explicitly found all candidate OpenAPI/Swagger endpoints returning 404, and docs pages described are static markdown guides, not runnable interactive references.

   • [probe] “PROBE openapi: all candidate paths 404 (https://www.meilisearch.com/openapi.json, https://www.meilisearch.com/swagger.json, https://www.meil…”
   • [probe] “PROBE docs-md: HTTP 200 at https://www.meilisearch.com/docs/getting_started/overview.md > ## Documentation Index > Fetch the complete docume…”

   proof ↗⚑ flag

   Elasticsearch—none0/10

   The evidence pack contains no mention of an interactive API reference with runnable examples (e.g., a Swagger/OpenAPI console or embedded code sandbox); in fact, probes explicitly show that openapi.json, llms.txt, and docs.md endpoints all return 404, indicating no discoverable machine-readable or interactive API spec was found. Missing for 10: any documentation of an interactive API explorer, runnable code snippets, or a working OpenAPI/Swagger reference.

   • [probe] “PROBE llms.txt: HTTP 404 at https://www.elastic.co/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://www.elastic.co/docs.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://www.elastic.co/openapi.json, https://www.elastic.co/swagger.json, https://www.elastic.co/api…”

   proof ↗⚑ flag

2. ai-native userDownload a machine-readable API spec (OpenAPI or equivalent)

   weight 2 · round drawn
   Meilisearch—none0/10

   The evidence pack explicitly shows a probe for OpenAPI/swagger specs at all common paths returning 404, and no documentation item mentions a downloadable machine-readable API spec.

   • [probe] “PROBE openapi: all candidate paths 404 (https://www.meilisearch.com/openapi.json, https://www.meilisearch.com/swagger.json, https://www.meil…”

   proof ↗⚑ flag

   Elasticsearch—none0/10

   The evidence pack's own probes checked for a machine-readable API spec (openapi.json, swagger.json, etc.) and found 404s at all candidate paths, and no docs item references a downloadable OpenAPI spec for Elasticsearch's REST API.

   • [probe] “PROBE openapi: all candidate paths 404 (https://www.elastic.co/openapi.json, https://www.elastic.co/swagger.json, https://www.elastic.co/api…”

   proof ↗⚑ flag

3. ai-native userTest against a sandbox environment without touching production data

   weight 1 · round to Elasticsearch
   Meilisearch~partialclaimed4/10

   Meilisearch's single-binary self-hosting model and simple local install (curl/Docker) let a developer spin up an isolated instance to test with sample data separate from production, and Meilisearch Cloud offers a 14-day free trial. However, there is no explicit 'sandbox' or staging-environment feature, no documented way to clone/mirror production data safely, and no AI-native tooling specifically for sandbox testing. missing for 10: a dedicated sandbox/staging mode, data-masking or safe-copy tooling for production data, and explicit AI-native sandbox workflow documentation.

   • [claimed-docs] “Meilisearch is a single binary with no external dependencies. You can run it on any Linux, macOS, or Windows machine, on bare metal or in co…”
   • [claimed-docs] “Download the latest stable release of Meilisearch with cURL. Launch Meilisearch to start the server.”
   • [claimed-docs] “curl -L https://install.meilisearch.com | sh”
   • [claimed-docs] “Install Meilisearch locally on Linux, macOS, or Windows using cURL, Docker, Homebrew, APT, or from source.”
   • [claimed-docs] “14-day free trial, no credit card required”

   proof ↗⚑ flag

   Elasticsearch~partialclaimed5/10

   Elasticsearch docs show a one-line Docker quickstart for local development/testing and a free serverless trial project, both of which let a user spin up an isolated instance separate from production (elastic-docs-5, elastic-docs-17, elastic-docs-8, elastic-docs-13). However, there is no explicit 'sandbox mode', synthetic test-data seeding, or documented data-isolation guarantee marketed for AI-native testing workflows. Missing for 10: an explicit sandbox/test-environment feature, guidance on isolating test data from production indices, and independent confirmation that local/trial instances are fully safe substitutes for production testing.

   • [claimed-docs] “curl -fsSL https://elastic.co/start-local | sh”
   • [claimed-docs] “Quickly set up Elasticsearch and Kibana in Docker for local development or testing, using this one-liner in the command line.”
   • [claimed-docs] “If you are a new user, sign up for a free 14-day trial to create a serverless project.”
   • [claimed-docs] “Elastic provides several self-managed and Elastic-managed options.”

   proof ↗⚑ flag

4. ai-native userRely on versioned APIs with a documented deprecation policy

   weight 2 · round drawn
   Meilisearch—none0/10

   The evidence pack contains no mention of API versioning scheme, version headers, or a documented deprecation policy anywhere in Meilisearch's docs, product pages, or community discussion. This is a fair axis for an API-first product like Meilisearch, but nothing in the pack substantiates it.

   ⚑ flag

   Elasticsearch—none0/10

   No evidence pack items address API versioning strategy, version compatibility guarantees, or a documented deprecation policy for Elasticsearch APIs; the pack focuses on search/vector features, serverless deployment, and community pricing/support complaints. Probes even show missing openapi.json and llms.txt, suggesting no discoverable machine-readable API spec, but nothing confirms or denies a deprecation policy.

   ⚑ flag

Hybrid

1. developerUse built-in or managed embedders so documents and queries are vectorized without running my own embedding pipeline

   weight 2 · round to Elasticsearch
   Meilisearch✓fullclaimed8/10

   Docs explicitly state that configuring an embedder makes Meilisearch auto-generate embeddings for documents (and by extension queries via hybrid search) so developers don't need to compute/manage embeddings themselves, and hybrid search combining full-text and semantic search is a first-class documented capability. Missing for 10: no explicit listing of which embedder providers/models are supported (OpenAI, HuggingFace, etc.) or independent hands-on confirmation of embedder setup ease.

   • [claimed-docs] “When you configure an embedder, Meilisearch automatically generates vector embeddings for every document in your index. You don't need to co…”
   • [claimed-docs] “Hybrid search combines two search strategies: full-text search (matching keywords) and semantic search (matching meaning).”
   • [claimed-docs] “Hybrid search combines two search strategies: full-text search (matching keywords) and semantic search (matching meaning). This gives users …”
   • [claimed-docs] “Match how people actually search. Combine keyword precision with AI that understands meaning and intent.”

   proof ↗⚑ flag

   Elasticsearch✓fullclaimed9/10

   Elasticsearch's semantic_text field and inference API automatically generate embeddings via configured ML models (built-in or managed), with docs explicitly stating no need to define model settings or build inference pipelines, plus support for external/hosted embedding models. This directly matches the story of vectorization without a self-run embedding pipeline. Missing for 10: independent/hands-on developer corroboration beyond vendor docs.

   • [claimed-docs] “When you index content into a `semantic_text` field, Elasticsearch automatically generates vector embeddings using a configured machine lear…”
   • [claimed-docs] “When you index content into a `semantic_text` field, Elasticsearch automatically generates vector embeddings using a configured machine lear…”
   • [claimed-docs] “All you need to do is create an index mapping to start ingesting, embedding, and querying data. There is no need to define model-related set…”
   • [claimed-docs] “All you need to do is create an index mapping to start ingesting, embedding, and querying data. There is no need to define model-related set…”
   • [claimed-docs] “The inference API workflow is more complex but offers greater control over the inference endpoint configuration.”
   • [claimed-docs] “You can deploy external or hosted embedding models, or bring your own pre-computed vectors.”

   proof ↗⚑ flag

2. developerRun hybrid search — semantic vector similarity fused with keyword matching — in a single query

   weight 3 · round drawn
   Meilisearch✓fullclaimed9/10

   Meilisearch's docs explicitly describe hybrid search as combining full-text (keyword) and semantic (vector) search in a single query, with automatic embedding generation and no manual embedding management, and a dedicated product page reiterates this capability. Community evidence corroborates general production reliability of Meilisearch's search features, though no independent hands-on report specifically validates hybrid search quality. Missing for 10: independent/hands-on verification specifically of hybrid search fusion behavior (most corroboration covers full-text/indexing performance, not hybrid semantic fusion).

   • [claimed-docs] “When you configure an embedder, Meilisearch automatically generates vector embeddings for every document in your index. You don't need to co…”
   • [claimed-docs] “Hybrid search combines two search strategies: full-text search (matching keywords) and semantic search (matching meaning).”
   • [claimed-docs] “Hybrid search combines two search strategies: full-text search (matching keywords) and semantic search (matching meaning). This gives users …”
   • [claimed-docs] “Match how people actually search. Combine keyword precision with AI that understands meaning and intent.”

   proof ↗⚑ flag

   Elasticsearch✓fullclaimed9/10

   Elastic's docs clearly describe hybrid search combining full-text and vector search in a single request, with RRF as the recommended fusion algorithm, plus semantic_text and dense_vector/sparse_vector support for embeddings. This is well-documented first-party capability directly matching the story; missing for 10: independent hands-on benchmark or third-party validation of the fused-query relevance quality.

   • [claimed-docs] “Hybrid search runs full-text search and vector search in one request.”
   • [claimed-docs] “We recommend implementing hybrid search with the reciprocal rank fusion (RRF) algorithm.”
   • [claimed-docs] “We recommend implementing hybrid search with the reciprocal rank fusion (RRF) algorithm. This approach merges rankings from the full-text an…”
   • [claimed-docs] “Hybrid search runs full-text search and vector search in one request... We recommend implementing hybrid search with the reciprocal rank fus…”
   • [claimed-docs] “We recommend implementing hybrid search with the [reciprocal rank fusion (RRF)](https://www.elastic.co/docs/reference/elasticsearch/rest-api…”
   • [claimed-docs] “Elasticsearch functions as a vector database when you store embeddings in `dense_vector` or `sparse_vector` fields and query them for simila…”
   • [claimed-docs] “When you index content into a `semantic_text` field, Elasticsearch automatically generates vector embeddings using a configured machine lear…”

   proof ↗⚑ flag

Rag

1. developerPower RAG and conversational answers on top of my indexes with documented retrieval or answer APIs

   weight 1 · round to Elasticsearch
   Meilisearch~partialclaimed6/10

   Meilisearch documents a dedicated 'conversational search' and 'RAG' product ('Let users ask questions and get real answers, grounded in your own content'; 'The retrieval layer your AI applications need') plus hybrid/semantic search with automatic embedding generation, which together form the retrieval backbone for RAG. However, the evidence pack only shows marketing-style product pages rather than technical API reference docs for a chat/answer endpoint, and there is no independent/hands-on confirmation that the conversational-answer feature works as described in production. Missing for 10: concrete API/endpoint documentation for the answer/chat capability, and independent corroboration of RAG/conversational-answer quality in real use.

   • [claimed-docs] “It stores your documents and embeddings, then exposes them through fast full-text search, semantic search, and conversational interfaces, al…”
   • [claimed-docs] “Let users ask questions and get real answers, grounded in your own content. No hallucinations, no guessing.”
   • [claimed-docs] “The retrieval layer your AI applications need. Give your models accurate, current context from your own data.”
   • [claimed-docs] “Hybrid search combines two search strategies: full-text search (matching keywords) and semantic search (matching meaning).”
   • [claimed-docs] “When you configure an embedder, Meilisearch automatically generates vector embeddings for every document in your index. You don't need to co…”

   proof ↗⚑ flag

   Elasticsearch~partialclaimed7/10

   Elasticsearch documents strong retrieval-side building blocks for RAG—automatic embeddings via semantic_text, dense/sparse vector search, hybrid search with RRF, and an inference API for embedding/model integration, and explicitly references 'RAG (Retrieval Augmented Generation) systems' as a use case. However, the evidence shows no native 'answer' or completion API that generates conversational answers itself—Elasticsearch remains the retrieval layer, with answer generation implied to depend on external LLM integration (e.g., via the inference API to a hosted model) rather than a documented end-to-end answer endpoint. Missing for 10: a documented native answer/completion API or an explicit RAG pipeline tool (e.g., a 'Playground' or answer-generation endpoint) demonstrating conversational answer synthesis directly from Elasticsearch, plus independent hands-on confirmation of a full RAG flow.

   • [claimed-docs] “When you index content into a `semantic_text` field, Elasticsearch automatically generates vector embeddings using a configured machine lear…”
   • [claimed-docs] “Hybrid search runs full-text search and vector search in one request.”
   • [claimed-docs] “We recommend implementing hybrid search with the reciprocal rank fusion (RRF) algorithm.”
   • [claimed-docs] “The inference API workflow is more complex but offers greater control over the inference endpoint configuration.”
   • [claimed-docs] “RAG (Retrieval Augmented Generation) systems”
   • [claimed-docs] “Elasticsearch functions as a vector database when you store embeddings in `dense_vector` or `sparse_vector` fields and query them for simila…”
   • [claimed-docs] “All you need to do is create an index mapping to start ingesting, embedding, and querying data. There is no need to define model-related set…”

   proof ↗⚑ flag

1. ai-native userPerform bulk operations across many items at once

   weight 2 · round to Meilisearch
   Meilisearch~partialcommunity5/10

   Meilisearch supports adding/indexing large document sets (community reports of importing millions of records and batch indexing working well), and its MCP integration lets an AI agent create indexes, add documents, and configure settings via natural language, implying bulk workflows. However, there's no explicit vendor documentation of a dedicated bulk API for large-scale updates/deletes, and independent reports show real limits: unpredictable RAM under heavy write/search load and indexing falling behind for hours with fast-changing datasets. missing for 10: explicit vendor-documented bulk add/update/delete API semantics, AI-driven bulk operation examples, and consistent independent confirmation of reliable bulk performance at scale.

   • [claimed-docs] “creating a project and an index, adding documents to it, and performing your first search with the default web interface”
   • [claimed-docs] “Once configured, you can create indexes, add documents, configure settings, and perform searches using natural language prompts.”
   • [community] “Running Meilisearch on a Hetzner AX52 (64GB RAM) with ~80,000,000 documents across 13 indexes; searches are fast and it's 'bored' at idle lo…”
   • [community] “We needed a 16GB machine to import all the data into Meilisearch, as batch indexing is quite memory intensive, but once it's all indexed we …”
   • [community] “I installed coolify on a VM and it had a one-click Meilisearch docker install. I sent 1,000,000 records to it and it 'just worked' on a litt…”
   • [community] “My team tried to use Meilisearch for large datasets; it's impossible to plan RAM usage. With little search traffic it used little RAM, but w…”
   • [community] “We've used Meilisearch in production and it is the closest thing to self hosted Algolia you can get. Unfortunately indexing performance for …”

   proof ↗⚑ flag

   Elasticsearch—none0/10

   The evidence pack contains no mention of Elasticsearch's bulk/batch APIs, batch indexing, multi-document updates, or any bulk-operation tooling for AI-native workflows — only single-document indexing (semantic_text), hybrid search, and serverless scaling are documented. Bulk operations are a plausible and expected capability for a search/database platform, so the axis applies, but no supporting evidence is present in this pack.

   ⚑ flag

2. ai-native userDefine rules that trigger actions automatically on events

   weight 3 · round drawn
   Meilisearch—none0/10

   Meilisearch's evidence describes ranking/relevancy rules (typo tolerance, ranking rules, dynamic search rules for boosting/pinning results) and tenant tokens applied per search request, but none of this constitutes user-defined rules that trigger automated actions in response to events (e.g., webhooks, event-driven workflows). No evidence of an events/triggers/actions automation system exists in the pack.

   • [claimed-docs] “Dynamic Search Rules ... Boost, pin, or bury results based on the context of each request”
   • [claimed-docs] “Personalization Adapt search results for each user based on their preferences and behavior ... Dynamic Search Rules Boost, pin, or bury resu…”
   • [claimed-docs] “Meilisearch contains seven built-in ranking rules in the following order: ["words", "typo", "proximity", "attributeRank", "sort", "wordPosit…”

   proof ↗⚑ flag

   Elasticsearch—none0/10

   The evidence pack contains no mention of Elasticsearch/Kibana alerting, Watcher, or any rule-based trigger-action automation for events; only search, vector, and serverless-scaling features are documented. While such a capability (e.g., Kibana Alerting) is plausible for this product category, no evidence supports it here.

   ⚑ flag

3. ai-native userSchedule recurring jobs or workflows

   weight 2 · round drawn
   Meilisearch—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

   Elasticsearch—none0/10

   No evidence describes any scheduling, cron, or recurring workflow/job orchestration capability in Elasticsearch; the pack covers search, vector/hybrid retrieval, serverless scaling, and MCP integration, none of which address recurring job scheduling.

   ⚑ flag

Onboarding

1. developerCreate an index, add documents, and run my first search within minutes of starting the quickstart

   weight 3 · round to Elasticsearch
   Meilisearch!disputedcontradicted6/10

   Meilisearch's docs include a dedicated quickstart (first_project.md) that walks through creating an index, adding documents, and running a first search via the web UI, plus a one-line curl install that gets a server running in seconds (docs-2, docs-12, docs-18, docs-44). Multiple community reports corroborate quick setup ('zero config', 'just worked', 'very easy' — comm-10, comm-17, comm-18), but at least one hands-on account explicitly contradicts the 'minutes' framing, saying creating an index, uploading documents, and changing settings took 'a week's worth of coding' (comm-8). missing for 10: independent hands-on confirmation of the exact quickstart flow timing, and resolution of the conflicting community report on setup effort.

   • [claimed-docs] “creating a project and an index, adding documents to it, and performing your first search with the default web interface”
   • [claimed-docs] “Download the latest stable release of Meilisearch with cURL. Launch Meilisearch to start the server.”
   • [claimed-docs] “curl -L https://install.meilisearch.com | sh”
   • [claimed-docs] “Install Meilisearch locally on Linux, macOS, or Windows using cURL, Docker, Homebrew, APT, or from source.”
   • [community] “I'm impressed. Blazing fast to index, like 10x more performant than using ElasticSearch/Searchkick; Blazing fast to search, at least 3x fast…”
   • [community] “Tested Meilisearch recently, was a great experience, getting a multi-index search running in our frontend was very easy. Just wish they had …”
   • [community] “I installed coolify on a VM and it had a one-click Meilisearch docker install. I sent 1,000,000 records to it and it 'just worked' on a litt…”
   • [community] “1. The rules for text searches are too strict by default and if the order of words is different, will result in no matches. 2. Creating an i…”

   proof ↗⚑ flag

   Elasticsearch~partialcommunity6/10

   Docs show a one-line local quickstart (curl install, Docker setup) and official client libraries, supporting fast setup, but no direct evidence of a documented end-to-end 'create index, add documents, search' walkthrough with actual commands, and community feedback notes documentation can be vague. missing for 10: explicit quickstart tutorial content showing index creation/document ingestion/search steps, independent hands-on confirmation of 'minutes' claim.

   • [claimed-docs] “curl -fsSL https://elastic.co/start-local | sh”
   • [claimed-docs] “Quickly set up Elasticsearch and Kibana in Docker for local development or testing, using this one-liner in the command line.”
   • [claimed-docs] “Elasticsearch is easy to use from most popular programming languages, thanks to the wide range of official libraries and developer tools ava…”
   • [claimed-docs] “If you are a new user, sign up for a free 14-day trial to create a serverless project.”
   • [community] “Elastic.co is probably one of the worst websites that somehow gained popularity despite its crappy pricing model and support. Their document…”

   proof ↗⚑ flag

Sdks

1. developerOfficial SDKs cover my language and framework, kept current across JavaScript, Python, PHP, Ruby, Go, and more

   weight 2 · round to Elasticsearch
   Meilisearch!disputedcontradicted6/10

   Meilisearch documents official typed SDKs for JavaScript, Python, PHP, Ruby, Go, Rust, Java, Swift, Dart, and .NET, with dedicated integration pages for JS/Python clients and a Laravel Scout driver, matching the story's core language list. However, community hands-on reports concretely contradict the 'kept current' claim: users reported the official Ruby/Rails gem falling out of sync with server releases, becoming incompatible for a period after server updates. Missing for 10: independent confirmation of SDK freshness across all listed languages, evidence of consistent release cadence/versioning parity, and no counter-examples for other languages besides the documented Ruby gem lag.

   • [claimed-docs] “Typed SDKs for JavaScript, Python, Ruby, PHP, Go, Rust, Java, Swift, Dart, and .NET.”
   • [claimed-docs] “The official JavaScript client for Meilisearch, with full TypeScript support for Node.js and browser environments.”
   • [claimed-docs] “The official Python client for Meilisearch with async support and type hints.”
   • [claimed-docs] “First-party Meilisearch driver for Laravel Scout, the official Laravel search package.”
   • [community] “The other issue we faced is their Rails gems falling out of step with the server, and when fixes came out, the Rails gem was incompatible fo…”

   proof ↗⚑ flag

   Elasticsearch~partialclaimed5/10

   Docs confirm Elasticsearch ships 'a wide range of official libraries and developer tools' for popular languages, but the pack gives no specifics naming JavaScript, Python, PHP, Ruby, Go clients or evidence they are kept current/version-matched. Missing for 10: explicit list of supported official SDKs per language, versioning/release cadence details, and independent corroboration of SDK quality or maintenance.

   • [claimed-docs] “Elasticsearch is easy to use from most popular programming languages, thanks to the wide range of official libraries and developer tools ava…”

   proof ↗⚑ flag

Ui libraries

1. developerOfficial UI component libraries let me assemble a full search interface — box, results, facets, pagination — without building it from scratch

   weight 2 · round to Meilisearch
   Meilisearch~partialclaimed6/10

   Meilisearch documents an official integration pairing it with React InstantSearch to 'build performant, responsive search interfaces,' which is a UI component library that supplies box, results, facets, and pagination widgets out of the box. However, the evidence pack only gives a single line about this integration with no detail on the specific components, customization, or coverage for other frameworks (Vue, Angular, vanilla JS widgets). missing for 10: broader multi-framework UI library docs, concrete examples of facet/pagination components, independent hands-on confirmation of assembling a full UI without custom code.

   • [claimed-docs] “Build performant, responsive search interfaces by pairing Meilisearch with React InstantSearch.”

   proof ↗⚑ flag

   Elasticsearch—none0/10

   Elasticsearch's evidence pack covers search/vector/hybrid features, serverless deployment, and clients, but contains no mention of official UI component libraries (search box, results, facets, pagination) for assembling a search interface. Search UI (Elastic's front-end library) is not referenced anywhere in the evidence.

   ⚑ flag

Connectors

1. founderIngest content with an official crawler or connectors instead of writing my own indexing pipeline

   weight 1 · round to Meilisearch
   Meilisearch~partialclaimed4/10

   Meilisearch lists official-looking connectors (meilisync for DB syncing, a Laravel Scout driver, various SDKs) that reduce custom pipeline work, but there is no evidence of an official web crawler (unlike Algolia's Crawler product) for ingesting arbitrary site/content, so founders would still need custom ingestion code for many content sources. missing for 10: an official website/content crawler, broader first-party connectors (CMS, cloud storage, SaaS apps) beyond meilisync and Laravel Scout, and independent evidence these connectors work reliably at scale.

   • [claimed-docs] “Sync databases with Meilisearch automatically.”
   • [claimed-docs] “First-party Meilisearch driver for Laravel Scout, the official Laravel search package.”
   • [claimed-docs] “The official JavaScript client for Meilisearch, with full TypeScript support for Node.js and browser environments.”
   • [claimed-docs] “The official Python client for Meilisearch with async support and type hints.”
   • [claimed-docs] “Official Meilisearch Docker images for easy deployment and development.”

   proof ↗⚑ flag

   Elasticsearch—none0/10

   The evidence pack contains no mention of Elastic's official web crawler or connectors for ingesting content (e.g., from S3, SharePoint, databases); it only covers semantic_text embedding generation, vector/hybrid search, and serverless deployment. Without documentation of a no-code ingestion pipeline via crawler/connectors, this story is unsupported by the given evidence.

   ⚑ flag

Ingestion

1. platform-engineerBulk-import millions of documents quickly, with async task tracking to know when indexing completes

   weight 2 · round to Meilisearch
   Meilisearch~partialcommunity6/10

   Community evidence strongly supports bulk-importing millions of documents (7M-article corpus, 80M-document deployment, 1M-record imports that 'just worked') and confirms Meilisearch uses batch indexing for large imports, but none of the evidence explicitly documents the async task/status API that lets a platform engineer poll for indexing completion. One report also notes indexing can fall behind for hours under heavy write load, showing throughput is not always guaranteed at scale. Missing for 10: explicit documentation/evidence of the task-status endpoint or webhook mechanism for tracking async indexing completion, and stronger evidence reconciling the indexing-lag report.

   • [community] “We use Meilisearch in production with a 7 million article corpus - it works really well.”
   • [community] “Running Meilisearch on a Hetzner AX52 (64GB RAM) with ~80,000,000 documents across 13 indexes; searches are fast and it's 'bored' at idle lo…”
   • [community] “We needed a 16GB machine to import all the data into Meilisearch, as batch indexing is quite memory intensive, but once it's all indexed we …”
   • [community] “I installed coolify on a VM and it had a one-click Meilisearch docker install. I sent 1,000,000 records to it and it 'just worked' on a litt…”
   • [community] “We've used Meilisearch in production and it is the closest thing to self hosted Algolia you can get. Unfortunately indexing performance for …”
   • [community] “I'm impressed. Blazing fast to index, like 10x more performant than using ElasticSearch/Searchkick; Blazing fast to search, at least 3x fast…”

   proof ↗⚑ flag

   Elasticsearch—none0/10

   The evidence pack contains no mention of Elasticsearch's bulk API, async reindex/_reindex task API, or the Tasks API for tracking long-running indexing operations — all material specific to this story is absent; only unrelated search, vector, and serverless/pricing content is provided.

   ⚑ flag

2. developerDocument adds, updates, and deletes become searchable in near real time without a full reindex

   weight 2 · round to Elasticsearch
   Meilisearch!disputedcontradicted5/10

   Meilisearch's docs describe adding/updating documents to an index and instant search, implying near-real-time indexing, and some users report blazing-fast indexing (meilisearch-comm-10, meilisearch-comm-6). However, hands-on production reports concretely contradict this for high-churn workloads: one team says 'indexing performance for constantly changing records wasn't great and Meilisearch would fall behind on indexing for hours' (meilisearch-comm-4), and others report unpredictable resource usage and write-scaling issues under heavy load (meilisearch-comm-3, meilisearch-comm-13). missing for 10: explicit vendor documentation of update latency/consistency guarantees, and resolution of the conflicting production reports on indexing lag under heavy write traffic.

   • [claimed-docs] “creating a project and an index, adding documents to it, and performing your first search with the default web interface”
   • [community] “I'm impressed. Blazing fast to index, like 10x more performant than using ElasticSearch/Searchkick; Blazing fast to search, at least 3x fast…”
   • [community] “We've used Meilisearch in production and it is the closest thing to self hosted Algolia you can get. Unfortunately indexing performance for …”
   • [community] “My team tried to use Meilisearch for large datasets; it's impossible to plan RAM usage. With little search traffic it used little RAM, but w…”
   • [community] “I've had issues scaling writes to it. You can get around it, but maybe this would be better in a high write environment.”
   • [community] “We needed a 16GB machine to import all the data into Meilisearch, as batch indexing is quite memory intensive, but once it's all indexed we …”

   proof ↗⚑ flag

   Elasticsearch~partialcommunity5/10

   Community evidence confirms Elasticsearch supports near-real-time search where indexed adds/updates/deletes become searchable after a refresh interval, and that this can be tuned to be 'practically real-time,' though with a performance trade-off ([elastic-comm-6]). However, none of the vendor documentation in this evidence pack explicitly describes the refresh_interval mechanism, versioning, or delete-visibility semantics that underlie this story, so the capability is only corroborated from a single community source rather than documented first-party. missing for 10: first-party docs on refresh_interval/NRT search semantics, documentation of update/delete visibility timing, independent benchmarks validating near-real-time latency under load.

   • [community] “The default refresh rate for ES is a minute or so... This means when you index a document, it won't be returned when you search for it until…”

   proof ↗⚑ flag

1. ai-native userDo everything through the API that I can do in the UI

   weight 2 · round to Meilisearch
   Meilisearch~partialprobed6/10

   Meilisearch is fundamentally API-first — indexes, documents, settings, ranking rules, facets, embeddings, and search are all configured and queried through the API, with only a thin default web interface for a first search (docs-2) and a Cloud dashboard for hosted features. This strongly implies API/UI parity by design, but there is no explicit documentation stating full feature parity, and a probe for a public OpenAPI spec returned 404s, so exhaustive API coverage isn't independently verifiable. Missing for 10: an explicit statement or audit confirming every UI-exposed action (e.g., Cloud dashboard features like clusterization, analytics dashboards) has a documented API equivalent, and a public OpenAPI/reference spec.

   • [claimed-docs] “creating a project and an index, adding documents to it, and performing your first search with the default web interface”
   • [claimed-docs] “Meilisearch is a single binary with no external dependencies. You can run it on any Linux, macOS, or Windows machine, on bare metal or in co…”
   • [claimed-docs] “Once configured, you can create indexes, add documents, configure settings, and perform searches using natural language prompts.”
   • [claimed-docs] “Guarantees the Read High Availability of the service with native support for clusterization.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://www.meilisearch.com/openapi.json, https://www.meilisearch.com/swagger.json, https://www.meil…”

   proof ↗⚑ flag

   Elasticsearch—none0/10

   The evidence pack describes Elasticsearch's REST API capabilities (search, vector, hybrid search, clients) but never addresses whether every UI (e.g., Kibana) feature is exposed via the API, and probes show no OpenAPI/machine-readable spec confirming full API surface parity.

   • [claimed-docs] “Elasticsearch is easy to use from most popular programming languages, thanks to the wide range of official libraries and developer tools ava…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://www.elastic.co/openapi.json, https://www.elastic.co/swagger.json, https://www.elastic.co/api…”

   proof ↗⚑ flag

2. ai-native userExport all of my data in open formats and leave

   weight 3 · round drawn
   Meilisearch—none0/10

   The evidence covers self-hosting, installation, and various search capabilities, but nowhere documents a data export/dump feature or open-format data portability mechanism that would let a user extract all their indexed documents and leave. Self-hosting (docs-11,12,44) implies data resides locally, but this is not the same as an explicit export tool or open-format guarantee.

   • [claimed-docs] “Meilisearch is a single binary with no external dependencies. You can run it on any Linux, macOS, or Windows machine, on bare metal or in co…”
   • [claimed-docs] “Download the latest stable release of Meilisearch with cURL. Launch Meilisearch to start the server.”
   • [claimed-docs] “Install Meilisearch locally on Linux, macOS, or Windows using cURL, Docker, Homebrew, APT, or from source.”

   proof ↗⚑ flag

   Elasticsearch—none0/10

   The evidence pack contains no documentation or community reports about exporting Elasticsearch data in open/portable formats (e.g., bulk export, snapshot/restore to open formats, or migration tooling); coverage is entirely about search, vector, and serverless features. Missing for 10: any mention of data export APIs, snapshot/restore in open formats, or migration/exit tooling.

   ⚑ flag

3. ai-native userRead the product's source under an open license

   weight 2 · round drawn
   Meilisearch—none0/10

   The evidence pack contains no mention of Meilisearch's source code repository, license type, or any open-source claim; only docs, integrations, and community sentiment about performance are present. Since an open-source license is a plausible and common attribute for a self-hosted database/search product, the axis applies, but no evidence supports it here.

   ⚑ flag

   Elasticsearch—none0/10

   The evidence pack contains no direct documentation of Elasticsearch's core source license or a link to its main source repository; the only GitHub reference is to the separate mcp-server-elasticsearch tool, not the Elasticsearch product itself. Community commentary even signals licensing churn (elastic-comm-2 calls it a 'formerly-OSS core'), but this doesn't rise to a concrete contradiction of a claimed capability—there's simply no evidence the story is fulfilled.

   • [claimed-docs] “elastic / mcp-server-elasticsearch Public”
   • [community] “Elastic.co has a lot of proprietary add-ons in their cloud and subscription tiers... Unfortunately for them a lot of users don't need any of…”

   proof ↗⚑ flag

4. ai-native userSelf-host the core product

   weight 3 · round to Meilisearch
   Meilisearch✓fullcommunity9/10

   Docs clearly describe self-hosting as a single dependency-free binary runnable via cURL, Docker, Homebrew, APT, or source on Linux/macOS/Windows, plus production guidance (reverse proxy, process manager, master key) and Kubernetes Helm charts/Docker images, and community reports confirm real-world self-hosted deployments at scale. Missing for 10: no independent audit of open-source license terms or feature parity vs. cloud version in the evidence pack.

   • [claimed-docs] “Meilisearch is a single binary with no external dependencies. You can run it on any Linux, macOS, or Windows machine, on bare metal or in co…”
   • [claimed-docs] “Download the latest stable release of Meilisearch with cURL. Launch Meilisearch to start the server.”
   • [claimed-docs] “curl -L https://install.meilisearch.com | sh”
   • [claimed-docs] “For production deployments, you will also need: A reverse proxy (Nginx or Caddy) for HTTPS termination A process manager (systemd)... A mast…”
   • [claimed-docs] “Install Meilisearch locally on Linux, macOS, or Windows using cURL, Docker, Homebrew, APT, or from source.”
   • [claimed-docs] “Helm charts for deploying Meilisearch on Kubernetes.”
   • [claimed-docs] “Official Meilisearch Docker images for easy deployment and development.”
   • [community] “Running Meilisearch on a Hetzner AX52 (64GB RAM) with ~80,000,000 documents across 13 indexes; searches are fast and it's 'bored' at idle lo…”
   • [community] “I installed coolify on a VM and it had a one-click Meilisearch docker install. I sent 1,000,000 records to it and it 'just worked' on a litt…”
   • [community] “I recently stood up the server in our k8s cluster and that part was also pretty easy, at least compared to elastic.”

   proof ↗⚑ flag

   Elasticsearch✓fullcommunity8/10

   Docs provide explicit self-managed deployment options, a local Docker/one-liner quickstart, and official client libraries, and community threads confirm real-world self-hosting (AWS ES, Elastic Cloud on Kubernetes, on-prem OSS core users) — clearly delivering self-hosting of the core product. Missing for 10: independent benchmark of self-hosted scaling/HA behavior and clearer distinction of which security/management features remain free vs paywalled in self-hosted mode.

   • [claimed-docs] “curl -fsSL https://elastic.co/start-local | sh”
   • [claimed-docs] “Quickly set up Elasticsearch and Kibana in Docker for local development or testing, using this one-liner in the command line.”
   • [claimed-docs] “Elastic provides several self-managed and Elastic-managed options.”
   • [claimed-docs] “Elasticsearch is easy to use from most popular programming languages, thanks to the wide range of official libraries and developer tools ava…”
   • [community] “Elastic.co has a lot of proprietary add-ons in their cloud and subscription tiers... Unfortunately for them a lot of users don't need any of…”
   • [community] “I found Elastic Cloud on K8s to be the best way to deploy and manage Elastic clusters on Kubernetes so far.”
   • [community] “For one, we don't have to pay for basic amenities like security and alerts. To heck with gouging the customer for basic feature sets. AWS ha…”

   proof ↗⚑ flag

Analytics

1. founderBuilt-in analytics show top queries, no-result queries, and click-through so I know what users search for and miss

   weight 2 · round to Meilisearch
   Meilisearch~partialclaimed6/10

   Meilisearch docs explicitly describe a built-in analytics capability tracking search queries, click events, and conversions to measure search quality (docs-9, docs-29, docs-54), which covers query tracking and click-through, but there is no explicit mention of a dedicated 'no-result queries' report/dashboard and no independent/hands-on corroboration of the analytics feature's UI or accuracy. missing for 10: explicit no-result-query reporting, a documented dashboard/UI view of these metrics, independent user confirmation of the analytics feature in practice.

   • [claimed-docs] “Track search queries, click events, and conversions to measure search quality and identify opportunities for improvement.”
   • [claimed-docs] “Meilisearch analytics helps you understand how users interact with your search. Track search queries, click events, and conversions to measu…”
   • [claimed-docs] “Track search events, user clicks, and conversions to measure and improve your search relevancy.”

   proof ↗⚑ flag

   Elasticsearch—none0/10

   Elasticsearch is a search/data engine; the evidence covers vector search, hybrid search, serverless scaling, and clients, but there is no mention of a built-in analytics dashboard for top queries, no-result queries, or click-through tracking. This is a plausible axis for a search product (e.g., Algolia offers this), so absence of evidence means 'none' rather than 'na'.

   ⚑ flag

Scale

1. platform-engineerDocumented scaling paths — clustering, replication, high availability — carry me from prototype to hundreds of millions of documents

   weight 2 · round to Elasticsearch
   Meilisearch~partialcommunity4/10

   Meilisearch Cloud advertises 'Read High Availability' with 'native support for clusterization' (meilisearch-docs-14), and there are Kubernetes Helm charts and Docker images for deployment (meilisearch-docs-69, meilisearch-docs-73), but the self-hosted OSS docs describe only a single-binary, no-external-dependency model with production notes limited to reverse proxy, systemd, and master keys (meilisearch-docs-11, meilisearch-docs-36) — no documented replication, sharding, or multi-node clustering path for self-managed deployments. Community reports are mixed on true large-scale operation: some reached tens of millions of documents successfully (meilisearch-comm-15, meilisearch-comm-14), but others report unpredictable RAM usage under heavy traffic and indexing falling behind for fast-changing datasets, forcing migration away (meilisearch-comm-3, meilisearch-comm-4, meilisearch-comm-13). Missing for 10: documented self-hosted clustering/sharding architecture, replication configuration guide, and independent validation of stable operation at 'hundreds of millions of documents' scale.

   • [claimed-docs] “Guarantees the Read High Availability of the service with native support for clusterization.”
   • [claimed-docs] “Meilisearch is a single binary with no external dependencies. You can run it on any Linux, macOS, or Windows machine, on bare metal or in co…”
   • [claimed-docs] “For production deployments, you will also need: A reverse proxy (Nginx or Caddy) for HTTPS termination A process manager (systemd)... A mast…”
   • [claimed-docs] “Helm charts for deploying Meilisearch on Kubernetes.”
   • [community] “Running Meilisearch on a Hetzner AX52 (64GB RAM) with ~80,000,000 documents across 13 indexes; searches are fast and it's 'bored' at idle lo…”
   • [community] “We use Meilisearch in production with a 7 million article corpus - it works really well.”
   • [community] “My team tried to use Meilisearch for large datasets; it's impossible to plan RAM usage. With little search traffic it used little RAM, but w…”
   • [community] “We've used Meilisearch in production and it is the closest thing to self hosted Algolia you can get. Unfortunately indexing performance for …”
   • [community] “I've had issues scaling writes to it. You can get around it, but maybe this would be better in a high write environment.”

   proof ↗⚑ flag

   Elasticsearch~partialcommunity6/10

   Elastic documents serverless auto-scaling, separated search/index tiers, and Elastic Cloud on K8s (community-corroborated) as scaling paths, and community evidence confirms real production clustering use, but the pack lacks first-party detail on core self-managed clustering/replication mechanics (shard allocation, replica configuration, data tiers) and includes independent evidence of data-loss risk under network partitions (Jepsen) and default near-real-time refresh trade-offs that temper HA claims. missing for 10: explicit documented self-managed clustering/replica/shard-allocation guidance, resolution of the Jepsen partition-tolerance concern, and independent benchmarks validating scale to hundreds of millions of documents.

   • [claimed-docs] “instead of managing clusters, nodes, data tiers, and scaling, you create serverless projects that are fully managed and automatically scaled…”
   • [claimed-docs] “instead of managing clusters, nodes, data tiers, and scaling, you create serverless projects that are fully managed and automatically scaled…”
   • [claimed-docs] “Management free: Elastic manages the underlying Elastic cluster, so you can focus on your data... Autoscaled: To meet your performance requi…”
   • [claimed-docs] “Separating search and index tiers enables workloads to be scaled independently and reliably, with optimized hardware for each use case.”
   • [claimed-docs] “when you have a short-term spike on the data you ingest, more resources are allocated for that period of time. When the spike is over, the s…”
   • [community] “I found Elastic Cloud on K8s to be the best way to deploy and manage Elastic clusters on Kubernetes so far.”
   • [community] “Elastic is great as a search index, not as a primary database. [referencing Aphyr's Jepsen analysis showing Elasticsearch can lose indexed d…”
   • [community] “The default refresh rate for ES is a minute or so... This means when you index a document, it won't be returned when you search for it until…”

   proof ↗⚑ flag

Self host

1. platform-engineerSelf-host the full engine — same features as the hosted product — on my own infrastructure

   weight 3 · round to Meilisearch
   Meilisearch~partialcommunity6/10

   Meilisearch is explicitly built to self-host as a single binary with no external dependencies (Docker, Kubernetes/Helm, systemd, reverse proxy guidance), and community reports confirm large-scale self-hosted production deployments (7M-100M+ document corpora, k8s clusters). However, some capabilities referenced in the docs — read high-availability/clusterization, and features like Analytics, Personalization and Dynamic Search Rules — are described on the Cloud/pricing pages rather than the self-hosting docs, suggesting these are not identical to the self-hosted OSS engine. Missing for 10: explicit confirmation that clustering/HA, analytics, and personalization are available (not cloud-exclusive) in the self-hosted binary, and independent verification of full feature parity between Cloud and self-hosted editions.

   • [claimed-docs] “Meilisearch is a single binary with no external dependencies. You can run it on any Linux, macOS, or Windows machine, on bare metal or in co…”
   • [claimed-docs] “Download the latest stable release of Meilisearch with cURL. Launch Meilisearch to start the server.”
   • [claimed-docs] “Meilisearch is a single binary with no external dependencies. You can run it on any Linux, macOS, or Windows machine”
   • [claimed-docs] “For production deployments, you will also need: A reverse proxy (Nginx or Caddy) for HTTPS termination A process manager (systemd)... A mast…”
   • [claimed-docs] “Install Meilisearch locally on Linux, macOS, or Windows using cURL, Docker, Homebrew, APT, or from source.”
   • [claimed-docs] “Helm charts for deploying Meilisearch on Kubernetes.”
   • [claimed-docs] “Guarantees the Read High Availability of the service with native support for clusterization.”
   • [claimed-docs] “Personalization Adapt search results for each user based on their preferences and behavior ... Dynamic Search Rules Boost, pin, or bury resu…”
   • [community] “Running Meilisearch on a Hetzner AX52 (64GB RAM) with ~80,000,000 documents across 13 indexes; searches are fast and it's 'bored' at idle lo…”
   • [community] “I recently stood up the server in our k8s cluster and that part was also pretty easy, at least compared to elastic.”

   proof ↗⚑ flag

   Elasticsearch!disputedcontradicted4/10

   Elastic docs confirm self-managed/local deployment exists (elastic-docs-5, elastic-docs-13, elastic-docs-17), but Elastic Cloud Serverless — with auto-scaling, cross-project search, and independent scaling of search/index tiers — is explicitly described as a hosted-only model that removes manual cluster management (elastic-docs-21, elastic-docs-25, elastic-docs-27, elastic-docs-32), meaning self-hosted deployments do not get the same operational features. Community evidence also recalls basic security features being paywalled in self-managed versions historically (elastic-comm-3, elastic-comm-9), further undercutting the 'same features' claim. Missing for 10: documentation showing self-managed clusters can match serverless autoscaling/cross-project search, and confirmation that all licensed features are available identically on-prem.

   • [claimed-docs] “curl -fsSL https://elastic.co/start-local | sh”
   • [claimed-docs] “Elastic provides several self-managed and Elastic-managed options.”
   • [claimed-docs] “Quickly set up Elasticsearch and Kibana in Docker for local development or testing, using this one-liner in the command line.”
   • [claimed-docs] “instead of managing clusters, nodes, data tiers, and scaling, you create serverless projects that are fully managed and automatically scaled…”
   • [claimed-docs] “instead of managing clusters, nodes, data tiers, and scaling, you create serverless projects that are fully managed and automatically scaled…”
   • [claimed-docs] “Separating search and index tiers enables workloads to be scaled independently and reliably, with optimized hardware for each use case.”
   • [claimed-docs] “instead of managing clusters, nodes, data tiers, and scaling, you create **serverless projects** that are fully managed and automatically sc…”
   • [community] “I'll never forgive Elastic for locking basic security features behind their paid licence. Over the years probably millions of people had the…”
   • [community] “We were hit by this on Kibana 6.x as I didn't read the x-pack trial properly. I thought at least login would be there. My bad. We added Ngin…”

   proof ↗⚑ flag

Pricing

1. founderCosts stay predictable as records and query volume grow — no surprise per-request cliffs

   weight 2 · round to Elasticsearch
   Meilisearch!disputedcontradicted3/10

   Docs describe self-hosting as a single binary you control (implying predictable infra costs) and reference a pricing page, but they never explicitly address predictable per-request/query pricing at scale. Concrete community evidence directly contradicts predictability: one team found RAM usage 'impossible to plan' and unpredictably expensive under heavy search traffic (comm-3), and another flags a steep jump from a free tier to $1200/month on Meilisearch Cloud (comm-2), i.e. real cost cliffs and unpredictable resource scaling. Missing for 10: first-party pricing documentation addressing predictability/no-cliff guarantees, and independent confirmation that costs scale linearly/predictably with volume.

   • [claimed-docs] “Dynamic Search Rules ... Boost, pin, or bury results based on the context of each request”
   • [claimed-docs] “Personalization Adapt search results for each user based on their preferences and behavior ... Dynamic Search Rules Boost, pin, or bury resu…”
   • [claimed-docs] “14-day free trial, no credit card required”
   • [community] “I was hoping the cloud version would be more appealing, granted there seems to be a generous free tier but the next option is $1200 a month?…”
   • [community] “My team tried to use Meilisearch for large datasets; it's impossible to plan RAM usage. With little search traffic it used little RAM, but w…”

   proof ↗⚑ flag

   Elasticsearch!disputedcontradicted4/10

   Elastic's serverless docs claim automatic, usage-based scaling that spins resources up for spikes and back down without user action (elastic-docs-33, elastic-docs-26), implying smooth cost scaling, but no pricing/cost caps or predictable-billing model is documented. Community evidence directly contradicts the 'no surprise cliffs' claim: teams report Elastic's licensing/subscription fees 'eat up significant portions of the project's profits' and describe its pricing as expensive and nickel-and-diming compared to alternatives (elastic-comm-4, elastic-comm-5, elastic-comm-10, elastic-comm-12, elastic-comm-13). Missing for 10: any first-party pricing/cost-predictability documentation, cost caps, or independent case studies showing stable costs at scale.

   • [claimed-docs] “when you have a short-term spike on the data you ingest, more resources are allocated for that period of time. When the spike is over, the s…”
   • [claimed-docs] “Management free: Elastic manages the underlying Elastic cluster, so you can focus on your data... Autoscaled: To meet your performance requi…”
   • [community] “Too late. We just deployed a new project with OpenSearch after learning from an Elastic salesperson that their licensing fees would eat up s…”
   • [community] “Elastic.co is probably one of the worst websites that somehow gained popularity despite its crappy pricing model and support. Their document…”
   • [community] “Elastic’s SaaS offering is incredibly expensive vs AWS Elasticsearch”
   • [community] “No one wants Elastic Search over Open Search. We're spending all our money on Open Search. Whenever I mention Elastic Search I may as well h…”
   • [community] “For one, we don't have to pay for basic amenities like security and alerts. To heck with gouging the customer for basic feature sets. AWS ha…”

   proof ↗⚑ flag

2. founderPublished per-unit pricing (searches, records, or nodes) lets me predict what search will cost before committing

   weight 3 · round drawn
   Meilisearch—none0/10

   The evidence pack shows a pricing page exists (mentioning feature tiers like 'Dynamic Search Rules' and a '14-day free trial') but never publishes concrete per-unit rates for searches, records, or nodes that a founder could use to forecast costs. Community comments actually highlight unpredictability (a jump to '$1200/month' with no visible per-unit basis, and RAM/cost unpredictability under load), reinforcing that no transparent per-unit pricing model is documented.

   • [claimed-docs] “Dynamic Search Rules ... Boost, pin, or bury results based on the context of each request”
   • [claimed-docs] “Personalization Adapt search results for each user based on their preferences and behavior ... Dynamic Search Rules Boost, pin, or bury resu…”
   • [claimed-docs] “14-day free trial, no credit card required”
   • [community] “I was hoping the cloud version would be more appealing, granted there seems to be a generous free tier but the next option is $1200 a month?…”
   • [community] “My team tried to use Meilisearch for large datasets; it's impossible to plan RAM usage. With little search traffic it used little RAM, but w…”

   proof ↗⚑ flag

   Elasticsearch—none0/10

   No evidence of published per-unit pricing (per search, record, or node) anywhere in the pack; only vague marketing claims ('30x faster... 50% cost of Datadog') and community complaints about opaque/expensive licensing, none of which constitute a transparent pricing calculator or rate card.

   • [claimed-docs] “Elasticsearch is 30x faster than Prom at 50% the cost of Datadog”
   • [community] “Elastic.co is probably one of the worst websites that somehow gained popularity despite its crappy pricing model and support. Their document…”
   • [community] “Elastic’s SaaS offering is incredibly expensive vs AWS Elasticsearch”
   • [community] “No one wants Elastic Search over Open Search. We're spending all our money on Open Search. Whenever I mention Elastic Search I may as well h…”

   proof ↗⚑ flag

1. ai-native userChoose where my data is stored (region/residency)

   weight 2 · round to Meilisearch
   Meilisearch~partialcommunity6/10

   Meilisearch ships as a self-hostable single binary/Docker/Kubernetes deployment, which lets an AI-native user run it in any jurisdiction of their choosing, satisfying the residency need via self-hosting rather than a built-in region picker. However, for the managed Meilisearch Cloud offering there's no documented list of selectable regions, and one community report notes only a Singapore region was available with no Australian option, suggesting limited choice for cloud users. Missing for 10: explicit multi-region selection UI/API for Meilisearch Cloud, first-party documentation listing available cloud regions, and confirmation that self-hosted deployments meet formal residency/compliance requirements.

   • [claimed-docs] “Meilisearch is a single binary with no external dependencies. You can run it on any Linux, macOS, or Windows machine, on bare metal or in co…”
   • [claimed-docs] “Download the latest stable release of Meilisearch with cURL. Launch Meilisearch to start the server.”
   • [claimed-docs] “Meilisearch is a single binary with no external dependencies. You can run it on any Linux, macOS, or Windows machine”
   • [claimed-docs] “For production deployments, you will also need: A reverse proxy (Nginx or Caddy) for HTTPS termination A process manager (systemd)... A mast…”
   • [claimed-docs] “Install Meilisearch locally on Linux, macOS, or Windows using cURL, Docker, Homebrew, APT, or from source.”
   • [claimed-docs] “Helm charts for deploying Meilisearch on Kubernetes.”
   • [community] “Tested Meilisearch recently, was a great experience, getting a multi-index search running in our frontend was very easy. Just wish they had …”

   proof ↗⚑ flag

   Elasticsearch~partialclaimed3/10

   Elastic offers both self-managed and Elastic-managed deployment options, which indirectly lets users control where their data physically resides (elastic-docs-13), and 'Cross-project search' claims data can stay in place without duplication (elastic-docs-34, elastic-docs-38). However, there is no explicit documentation of cloud region/residency selection controls for Elastic Cloud or Serverless projects. Missing for 10: explicit region-selection UI/API documentation, named regional data-residency guarantees, and independent confirmation of residency compliance.

   • [claimed-docs] “Elastic provides several self-managed and Elastic-managed options.”
   • [claimed-docs] “Cross-project search: Query isolated projects in-place. Unify global visibility without paying to move or duplicate your data.”
   • [claimed-docs] “CPS is GA: one unified view across your Serverless projects while data stays in place.”

   proof ↗⚑ flag

2. ai-native userControl data retention and deletion

   weight 2 · round drawn
   Meilisearch—none0/10

   The evidence pack never documents any explicit data-retention or document/index-deletion controls (e.g., delete-document API, TTL, data export/erasure tooling). Self-hosting evidence (meilisearch-docs-11/12/18/19) implies a user could control their own infrastructure, but this is indirect and not a documented retention/deletion feature; community evidence (meilisearch-comm-12) even flags on-by-default analytics tracking with no clear opt-out as a privacy concern rather than showing a retention control. Missing for 10: explicit documentation of deletion APIs, retention policies, TTLs, or data-export/erasure tooling.

   • [claimed-docs] “Meilisearch is a single binary with no external dependencies. You can run it on any Linux, macOS, or Windows machine, on bare metal or in co…”
   • [claimed-docs] “Download the latest stable release of Meilisearch with cURL. Launch Meilisearch to start the server.”
   • [claimed-docs] “Track search queries, click events, and conversions to measure search quality and identify opportunities for improvement.”
   • [community] “The practice itself is malignant [on-by-default analytics]; either explicitly ask upon first run or require an env variable to enable it.”

   proof ↗⚑ flag

   Elasticsearch—none0/10

   The evidence pack contains no documentation of Elasticsearch's data retention or deletion controls (e.g., Index Lifecycle Management, TTL, delete-by-query APIs, or privacy/compliance tooling) — it focuses entirely on search, vector/embedding features, and serverless deployment. Since retention/deletion is a fair and applicable axis for a data platform like Elasticsearch, but no supporting evidence is present, this is 'none' rather than 'na'.

   ⚑ flag

3. ai-native userOpt out of telemetry and usage tracking

   weight 2 · round drawn
   Meilisearch—none0/10

   No documentation in the evidence pack describes a telemetry/analytics opt-out mechanism. A community comment explicitly criticizes Meilisearch's on-by-default analytics as a practice needing improvement ('either explicitly ask upon first run or require an env variable to enable it'), indicating no clear, documented way to opt out is evidenced here.

   • [community] “The practice itself is malignant [on-by-default analytics]; either explicitly ask upon first run or require an env variable to enable it.”

   proof ↗⚑ flag

   Elasticsearch—none0/10

   No evidence in the pack addresses telemetry opt-out or usage tracking controls for Elasticsearch; the docs/community items cover search features, deployment, pricing, and reliability, not privacy/telemetry settings. Missing for 10: any documentation of telemetry collection, opt-out mechanism, or privacy controls.

   ⚑ flag

Curation

1. developerDefine synonyms and curate results — pin, boost, or hide specific hits for specific queries

   weight 2 · round to Meilisearch
   Meilisearch✓fullclaimed8/10

   Meilisearch documents synonym configuration directly (synonyms.md) and offers editable ranking rules for relevance tuning, plus paid "Dynamic Search Rules" that explicitly boost, pin, or bury results per query context. Community evidence corroborates general relevancy/production use, though no independent hands-on confirmation specifically of pin/boost/hide curation exists. Missing for 10: independent/community validation specifically of the pin/boost/hide curation feature (only vendor pricing page mentions it) and detail on the 'hide' mechanism beyond bury.

   • [claimed-docs] “If multiple words have an equivalent meaning in your dataset, you can create a list of synonyms. This will make your search results more rel…”
   • [claimed-docs] “you can create a list of synonyms. This will make your search results more relevant.”
   • [claimed-docs] “If multiple words have an equivalent meaning in your dataset, you can create a list of synonyms”
   • [claimed-docs] “Dynamic Search Rules ... Boost, pin, or bury results based on the context of each request”
   • [claimed-docs] “Personalization Adapt search results for each user based on their preferences and behavior ... Dynamic Search Rules Boost, pin, or bury resu…”
   • [claimed-docs] “Meilisearch contains seven built-in ranking rules in the following order: ["words", "typo", "proximity", "attributeRank", "sort", "wordPosit…”
   • [claimed-docs] “Meilisearch contains seven built-in ranking rules in the following order... Depending on your needs, you might want to change this order.”

   proof ↗⚑ flag

   Elasticsearch—none0/10

   The evidence pack covers vector/hybrid search, serverless deployment, and pricing/community sentiment, but contains no mention of synonym definitions, curated results, pinning/boosting/hiding documents, or any relevance-tuning APIs (e.g., synonym API, query rules). No documentation or community evidence addresses this capability at all.

   ⚑ flag

Ranking

1. developerShape relevance with custom ranking rules and business signals (popularity, recency, margin) beyond textual matching

   weight 2 · round to Meilisearch
   Meilisearch✓fullclaimed8/10

   Meilisearch documents customizable ranking rules (including sort and attributeRank) that can be reordered, plus sortable attributes for popularity/recency/margin-style business signals, and Cloud-tier features like Dynamic Search Rules to boost/pin/bury results by context. Missing for 10: independent hands-on evidence of complex multi-signal ranking tuning in production, and the boost/pin/bury 'Dynamic Search Rules' feature is only documented on the pricing page (Cloud-only) rather than core docs.

   • [claimed-docs] “Meilisearch contains seven built-in ranking rules in the following order: ["words", "typo", "proximity", "attributeRank", "sort", "wordPosit…”
   • [claimed-docs] “Meilisearch contains seven built-in ranking rules in the following order... Depending on your needs, you might want to change this order.”
   • [claimed-docs] “Meilisearch contains seven built-in ranking rules in the following order: words, typo, proximity, attributeRank, sort, wordPosition, exactne…”
   • [claimed-docs] “Depending on your needs, you might want to change this order.”
   • [claimed-docs] “Dynamic Search Rules ... Boost, pin, or bury results based on the context of each request”
   • [claimed-docs] “Personalization Adapt search results for each user based on their preferences and behavior ... Dynamic Search Rules Boost, pin, or bury resu…”

   proof ↗⚑ flag

   Elasticsearch—none0/10

   The evidence pack covers semantic/vector search, hybrid search with RRF, and serverless deployment, but contains no mention of Elasticsearch's ranking customization tools (e.g., function_score, script_score, boosting, decay functions) that would let a developer inject business signals like popularity, recency, or margin into relevance scoring. Missing for 10: any documentation of custom scoring functions, field/query boosting for non-textual signals, or examples combining business metrics with relevance ranking.

   ⚑ flag

2. platform-engineerInspect ranking scores or explanations to understand exactly why a result ranked where it did

   weight 1 · round drawn
   Meilisearch—none0/10

   The evidence describes the seven built-in ranking rules and that their order can be customized, but nothing in the pack shows a mechanism for inspecting per-result ranking scores or a detailed ranking explanation for why a specific document ranked where it did. missing for 10: any documentation of a ranking-score/explain API or debug output, independent confirmation of such a feature being used for relevance tuning.

   • [claimed-docs] “Meilisearch contains seven built-in ranking rules in the following order: ["words", "typo", "proximity", "attributeRank", "sort", "wordPosit…”
   • [claimed-docs] “Meilisearch contains seven built-in ranking rules in the following order... Depending on your needs, you might want to change this order.”
   • [claimed-docs] “Depending on your needs, you might want to change this order.”
   • [claimed-docs] “Meilisearch contains seven built-in ranking rules in the following order”

   proof ↗⚑ flag

   Elasticsearch—none0/10

   Elasticsearch famously offers an Explain API and query profiling for ranking transparency, but none of the evidence pack mentions explain, _explain, profile API, or scoring breakdowns — the pack only covers hybrid search, RRF, vector search, serverless, and MCP topics. Absence of evidence for this applicable relevance-tuning capability means it cannot be credited here.

   ⚑ flag

Experience

1. developerServe query suggestions and autocomplete backed by real search traffic or a suggestions index

   weight 2 · round to Meilisearch
   Meilisearch~partialclaimed5/10

   Meilisearch documents facet search explicitly for powering autocomplete/type-ahead interfaces, and its analytics feature tracks search queries, clicks, and conversions that could inform a suggestions strategy, but there is no documented dedicated 'suggestions index' or query-log-driven autocomplete feature (e.g., popular/trending query suggestions) — only facet-value autocomplete and general query analytics. missing for 10: a first-party suggestions/autocomplete-from-search-traffic feature, documentation on building a suggestions index from query logs, and independent evidence of this pattern being used in production.

   • [claimed-docs] “It is typically used to power auto-complete and type-ahead interfaces on top of filter menus, especially when a facet has too many distinct …”
   • [claimed-docs] “Facet search is a dedicated endpoint for searching through the values of a single facet. It is typically used to power auto-complete and typ…”
   • [claimed-docs] “Facet search is a dedicated endpoint for searching through the values of a single facet.”
   • [claimed-docs] “Track search queries, click events, and conversions to measure search quality and identify opportunities for improvement.”
   • [claimed-docs] “Meilisearch analytics helps you understand how users interact with your search. Track search queries, click events, and conversions to measu…”
   • [claimed-docs] “Track search events, user clicks, and conversions to measure and improve your search relevancy.”

   proof ↗⚑ flag

   Elasticsearch—none0/10

   The evidence pack covers semantic/vector/hybrid search, serverless deployment, and MCP tooling, but contains no mention of Elasticsearch's suggestion/autocomplete-specific capabilities (e.g., completion suggester, search-as-you-type, edge n-grams) or any pattern for building suggestions from real query/traffic logs. Since autocomplete is a plausible axis for a search engine but no evidence supports it here, verdict is none.

   ⚑ flag

2. developerDeliver as-you-type instant search with millisecond responses so results update on every keystroke

   weight 3 · round to Meilisearch
   Meilisearch✓fullcommunity8/10

   Meilisearch is purpose-built for instant, typo-tolerant, millisecond full-text search with ranking rules, and community reports corroborate real-world speed (10x faster indexing/search than Elasticsearch, sub-second at scale) even though some users note RAM/write scaling issues under heavy load. Docs explicitly market 'instant' typo-tolerant search with no tuning required, and hands-on reports confirm fast search at production scale. missing for 10: no explicit documented millisecond latency benchmark or as-you-type debounce guidance, and some community reports of indexing lag/RAM unpredictability under heavy write load temper full confidence.

   • [claimed-docs] “Typo tolerance helps users find relevant results even when their search queries contain spelling mistakes or typos, for example, typing `phn…”
   • [claimed-docs] “Meilisearch contains seven built-in ranking rules in the following order: ["words", "typo", "proximity", "attributeRank", "sort", "wordPosit…”
   • [claimed-docs] “Help users find what they want instantly, even when they misspell or only remember part of it. No tuning required.”
   • [community] “I'm impressed. Blazing fast to index, like 10x more performant than using ElasticSearch/Searchkick; Blazing fast to search, at least 3x fast…”
   • [community] “We use Meilisearch in production with a 7 million article corpus - it works really well.”
   • [community] “Running Meilisearch on a Hetzner AX52 (64GB RAM) with ~80,000,000 documents across 13 indexes; searches are fast and it's 'bored' at idle lo…”
   • [community] “My team tried to use Meilisearch for large datasets; it's impossible to plan RAM usage. With little search traffic it used little RAM, but w…”
   • [community] “We've used Meilisearch in production and it is the closest thing to self hosted Algolia you can get. Unfortunately indexing performance for …”

   proof ↗⚑ flag

   Elasticsearch—none0/10

   The evidence pack contains general marketing claims about speed ('unprecedented speed', '30x faster than Prom') and hybrid/vector search docs, but nothing describes autocomplete-style, keystroke-driven instant search (e.g. completion suggester, search-as-you-type field, edge n-gram) or millisecond query latency for typeahead use cases. Community notes even highlight refresh-interval delays affecting near-real-time indexing, but this doesn't establish the as-you-type capability itself.

   • [claimed-docs] “Get relevant results at unprecedented speed with open and flexible enterprise solutions.”
   • [claimed-docs] “Elasticsearch is 30x faster than Prom at 50% the cost of Datadog”
   • [community] “The default refresh rate for ES is a minute or so... This means when you index a document, it won't be returned when you search for it until…”

   proof ↗⚑ flag

3. developerSearches tolerate typos and misspellings out of the box, with tunable rules for when and how fuzzy matching applies

   weight 3 · round to Meilisearch
   Meilisearch✓fullcommunity8/10

   Docs confirm typo tolerance is enabled by default (docs-3, docs-37, docs-60) and is tunable per index via minWordSizeForTypos and other settings (docs-22, docs-31), giving developers control over when/how fuzzy matching applies. Community feedback (comm-10) corroborates a 'zero config' experience, though no independent test specifically stresses typo-matching edge cases. Missing for 10: independent hands-on verification of typo-tolerance accuracy/limits and more detail on advanced tuning knobs beyond minWordSizeForTypos.

   • [claimed-docs] “Typo tolerance helps users find relevant results even when their search queries contain spelling mistakes or typos, for example, typing `phn…”
   • [claimed-docs] “You can override these default settings using the minWordSizeForTypos object.”
   • [claimed-docs] “You can configure the typo tolerance feature for each index”
   • [claimed-docs] “Typo tolerance helps users find relevant results even when their search queries contain spelling mistakes or typos”
   • [claimed-docs] “Help users find what they want instantly, even when they misspell or only remember part of it. No tuning required.”
   • [community] “I'm impressed. Blazing fast to index, like 10x more performant than using ElasticSearch/Searchkick; Blazing fast to search, at least 3x fast…”

   proof ↗⚑ flag

   Elasticsearch—none0/10

   The evidence pack focuses on vector/semantic/hybrid search, serverless deployment, and pricing/support commentary, but contains no mention of fuzzy matching, typo tolerance, or edit-distance/fuzziness query parameters that would support this story.

   ⚑ flag

Filtering

1. developerBuild faceted navigation — filters with live counts across categories, ranges, and attributes — from a single query

   weight 2 · round to Meilisearch
   Meilisearch✓fullcommunity9/10

   Meilisearch's docs directly describe faceted navigation with live counts (e.g., 'Color: Red (12), Blue (8)'), filtering by categories/ranges/attributes (brand, color, size, price range), a dedicated facet search endpoint for large facet lists, and this all being returned from a single query/API call alongside search results. Community evidence corroborates real-world use of filtering/faceting features at scale. missing for 10: independent hands-on benchmark specifically validating live facet counts performance/accuracy at scale.

   • [claimed-docs] “E-commerce faceted navigation: Let shoppers narrow products by brand, color, size, and price range while displaying counts for each option.”
   • [claimed-docs] “"Color: Red (12), Blue (8)"”
   • [claimed-docs] “Faceting returns aggregated counts for field values, powering category navigation in your UI”
   • [claimed-docs] “Facet search is a dedicated endpoint for searching through the values of a single facet. It is typically used to power auto-complete and typ…”
   • [claimed-docs] “Facets are filters that also return distribution data. Use them together to build interactive, ecommerce-style navigation.”
   • [claimed-docs] “Filtering, sorting, and faceting are three complementary tools for refining search results”
   • [claimed-docs] “Facet search is a dedicated endpoint for searching through the values of a single facet.”
   • [claimed-docs] “Filters, ranges, and refinements that turn a long list of results into the right answer.”
   • [community] “Tested Meilisearch recently, was a great experience, getting a multi-index search running in our frontend was very easy. Just wish they had …”

   proof ↗⚑ flag

   Elasticsearch~partialclaimed4/10

   Elasticsearch's docs confirm it can combine full-text search, structured filters, and aggregations 'in one engine' (elastic-docs-4), which is the mechanism needed for faceted navigation, but the evidence pack contains no dedicated documentation, examples, or API references for building terms/range/histogram aggregations for facet counts, nor any walkthrough of a single query returning filtered results plus live facet counts. Missing for 10: explicit aggregations API docs/examples, terms/range/date-histogram facet examples, guidance on combining filters+aggs in one request, and independent/hands-on validation of facet performance.

   • [claimed-docs] “Elasticsearch can combine vector search with full-text search, structured filters, aggregations, and hybrid retrieval in one engine”

   proof ↗⚑ flag

Tenancy

1. developerScoped or tenant tokens restrict each end user's searches to their own documents without separate indexes per user

   weight 2 · round to Meilisearch
   Meilisearch✓fullclaimed8/10

   Meilisearch's docs explicitly describe tenant tokens as short-lived, scoped credentials that embed filters/search rules to restrict each user to their own data without needing separate indexes per tenant, directly matching the story (e.g., 'No need for separate indexes or infrastructure per customer', 'Each tenant gets isolated access through secure tokens'). This is a well-documented first-party feature analogous to Algolia secured keys / Postgres RLS. Missing for 10: independent/hands-on community verification specifically of tenant token security in production multi-tenant setups (community evidence covers performance/RAM/indexing issues, not this security feature).

   • [claimed-docs] “Tenant tokens are short-lived, scoped credentials generated from an API key. They embed search rules (filters) that automatically apply to e…”
   • [claimed-docs] “Tenant tokens are short-lived, scoped credentials generated from an API key. They embed search rules (filters) that automatically apply to e…”
   • [claimed-docs] “tenant tokens serve a similar purpose to Algolia's secured API keys or PostgreSQL's row-level security (RLS)”
   • [claimed-docs] “Tenant tokens... embed search rules (filters) that automatically apply to every search request, ensuring users only see their own data.”
   • [claimed-docs] “Tenant tokens restrict search results to a specific tenant. Documents are filtered at query time. No data ever crosses boundaries.”
   • [claimed-docs] “API keys authenticate requests, while tenant tokens restrict what data each user can see within a shared index.”
   • [claimed-docs] “Meilisearch handles multi-tenancy at the search level. Each tenant gets isolated access through secure tokens. No need for separate indexes …”

   proof ↗⚑ flag

   Elasticsearch—none0/10

   The evidence pack contains no mention of document-level security, field/document-level access control, API key privileges scoped to queries, or search templates restricting results per user — the actual mechanisms Elasticsearch offers for this use case are absent from the pack. Nothing here shows scoped/tenant tokens restricting per-user search results.

   ⚑ flag