Typesense 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 to Elasticsearch
   Typesense~partialprobed7/10

   Typesense's REST API is thoroughly documented for the full workflow — creating a collection, adding documents, searching, filtering, faceting (typesense-docs-8/29/37) — and the dedicated MCP server for Typesense Cloud explicitly lets an AI agent 'create and configure clusters, build collections, index your data, tune search and read metrics, all from the conversation' (typesense-docs-43), satisfying the no-dashboard requirement via API/MCP. However, no CLI tool for creating indexes/adding docs/querying is evidenced — the CLI probe (typesense-probe-4) only points to installation instructions, not an actual query/index CLI. Missing for 10: a documented standalone CLI for index/document/query operations, and independent hands-on confirmation of the MCP server workflow.

   • [claimed-docs] “Connect your AI agent to Typesense Cloud and it can create and configure clusters, build collections, index your data, tune search and read …”
   • [claimed-docs] “Creating a "books" collection ... Adding books to the collection ... Searching for books ... Filtering results ... Faceting”
   • [claimed-docs] “Creating a "books" collection”
   • [claimed-docs] “Filtering results”
   • [probe] “official CLI documented at https://typesense.org/docs/guide/install-typesense.html”

   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 drawn
   Typesense✓fullclaimed7/10

   Typesense explicitly documents an MCP server for Typesense Cloud that lets an AI agent create/configure clusters, build collections, index data, tune search, and read metrics — directly matching the query/analytics/index-operations tool-surface story. Missing for 10: independent or hands-on verification of the MCP server's behavior, a full operation/tool list, and confirmation it works outside Typesense Cloud (self-hosted).

   • [claimed-docs] “Connect your AI agent to Typesense Cloud and it can create and configure clusters, build collections, index your data, tune search and read …”
   • [claimed-docs] “Natural Language Search ... Typesense for AI Agents”

   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 Typesense
   Typesense✓fullprobed8/10

   A probe confirms a live, well-formed llms.txt at typesense.org/llms.txt describing Typesense for developers and AI agents, and docs explicitly include an 'AI Agents' guide and MCP server integration (typesense-probe-1, typesense-docs-17, typesense-docs-43). missing for 10: no independent/community corroboration of agents actually using llms.txt successfully, and a docs-markdown endpoint (docs/.md) returned 404 suggesting incomplete agent-oriented doc surface.

   • [probe] “PROBE llms.txt: HTTP 200 at https://typesense.org/llms.txt # Typesense > Typesense is an open source search engine for developers and AI ag…”
   • [claimed-docs] “Natural Language Search ... Typesense for AI Agents”
   • [claimed-docs] “Connect your AI agent to Typesense Cloud and it can create and configure clusters, build collections, index your data, tune search and read …”
   • [probe] “PROBE docs-md: HTTP 404 at https://typesense.org/docs/.md”

   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
   Typesense~partialprobed6/10

   Typesense supports Docker/binary installs, Docker Compose/Kubernetes/Terraform deployment, and docs explicitly mention Testcontainers and GitHub Actions for running tests, indicating it can be run headlessly and driven via CI automation. However, there's no dedicated CI/CD pipeline guide, no first-party GitHub Actions workflow templates, and no explicit 'headless mode' or automation-focused CLI documentation beyond install/test mentions. missing for 10: dedicated CI/CD automation guide, official GitHub Actions templates/workflows, explicit headless-mode documentation, and independent hands-on CI usage reports.

   • [claimed-docs] “Running Tests with Testcontainers ... Running Tests in Github Actions”
   • [claimed-docs] “Docker, Docker Compose, Kubernetes, Mac via Homebrew, Mac Binary, DEB package on Ubuntu/Debian, RPM package on CentOS/RHEL, Linux Binary”
   • [claimed-docs] “Terraform Module”
   • [probe] “official CLI documented at https://typesense.org/docs/guide/install-typesense.html”

   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 Elasticsearch
   Typesense~partialclaimed6/10

   Typesense documents an official MCP server for Typesense Cloud that lets an AI agent create/configure clusters, build collections, index data, and tune search directly from a conversation, which is a genuine first-party MCP server offering. However this is scoped to the Cloud product (not the open-source self-hosted server), and there is no independent/hands-on corroboration of it working, nor detail on the full tool surface. missing for 10: independent corroboration/hands-on testing of the MCP server, confirmation it applies to self-hosted Typesense, full list of supported MCP tools/operations.

   • [claimed-docs] “Connect your AI agent to Typesense Cloud and it can create and configure clusters, build collections, index your data, tune search and read …”

   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
   Typesense—none0/10

   The evidence covers installation methods (Docker, packages, binaries) and an MCP server for AI agents, but there is no evidence of a distinct official CLI tool for AI-native command-line workflows; the one probe labeled 'official CLI documented' just points to the generic install-methods page, not an actual CLI feature description.

   • [claimed-docs] “Docker, Docker Compose, Kubernetes, Mac via Homebrew, Mac Binary, DEB package on Ubuntu/Debian, RPM package on CentOS/RHEL, Linux Binary”
   • [claimed-docs] “Docker Docker Compose Kubernetes Mac via Homebrew Mac Binary DEB package on Ubuntu/Debian RPM package on CentOS/RHEL Linux Binary Windows (W…”
   • [claimed-docs] “Docker Compose Kubernetes Mac via Homebrew Mac Binary DEB package on Ubuntu/Debian RPM package on CentOS/RHEL Linux Binary Windows (WSL) Ter…”
   • [probe] “official CLI documented at https://typesense.org/docs/guide/install-typesense.html”

   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 Typesense
   Typesense✓fullprobed8/10

   Typesense ships documented REST API reference pages (e.g. api/curation.html), an llms.txt explicitly framing itself as 'for developers and AI agents,' and a dedicated MCP server letting AI agents create clusters, index data, and tune search entirely via API/conversation — strong evidence of a documented, AI-drivable public API surface. Missing for 10: a discoverable machine-readable OpenAPI/Swagger spec (probe found 404s at all standard OpenAPI paths) and independent hands-on confirmation of API completeness beyond vendor docs.

   • [claimed-docs] “Copy Markdown”
   • [claimed-docs] “Connect your AI agent to Typesense Cloud and it can create and configure clusters, build collections, index your data, tune search and read …”
   • [probe] “PROBE llms.txt: HTTP 200 at https://typesense.org/llms.txt # Typesense > Typesense is an open source search engine for developers and AI ag…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://typesense.org/openapi.json, https://typesense.org/swagger.json, https://typesense.org/api/op…”

   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 drawn
   Typesense—none0/10

   The evidence pack only shows a general 'Security' section heading in the production docs and an MCP integration that grants an AI agent broad access to create/configure clusters and read metrics — not evidence of scoped or least-privilege API key issuance for agents. No documentation of restricted/scoped API keys, permission scopes, or credential minimization for agent use is present.

   • [claimed-docs] “Production Best Practices ... Configuration ... Monitoring ... Search Relevance ... Security ... Schema Management”
   • [claimed-docs] “Production Best Practices ... Monitoring ... Search Relevance ... Security ... Schema Management”
   • [claimed-docs] “Connect your AI agent to Typesense Cloud and it can create and configure clusters, build collections, index your data, tune search and read …”

   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 to Elasticsearch
   Typesense—none0/10

   The evidence pack documents Typesense's installation options, CLI, API endpoints, MCP server for AI agents, and llms.txt, but contains no citation of official client SDKs (e.g., language libraries) that an AI-native developer could build against. Absence of evidence for an applicable capability yields 'none'.

   ⚑ 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
   Typesense—none0/10

   No evidence anywhere in the pack of a webhook or event subscription mechanism for Typesense; the product surface described is search/indexing APIs, collections, ranking, and an MCP server for AI agents, none of which constitute an event/webhook subscription system.

   ⚑ 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
   Typesense~partialclaimed4/10

   Typesense documents Natural Language Search and 'built-in retrieval-augmented generation (RAG)' plus LLM integrations that let queries be interpreted and answered conversationally, which can surface AI-derived insights from indexed data, but this is a developer-facing API capability requiring integration, not a built-in insights/suggestions UI for end users inside the product. missing for 10: evidence of an out-of-the-box insights/suggestions UI or dashboard, first-party product screenshots of RAG-generated insights in use, independent user reports validating the RAG/NLS features work as advertised.

   • [claimed-docs] “Typesense is more battle-tested in high-scale production environments, and includes automatic Raft leader election in its open-source server…”
   • [claimed-docs] “It also offers native integrations with LLMs of your choice to enable Natural Language Search and built-in retrieval-augmented generation (R…”
   • [claimed-docs] “Natural Language Search ... Typesense for AI Agents”

   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
   Typesense—none0/10

   Typesense's AI-agent evidence (MCP server) is only conversational/interactive—an agent issues commands during a live session ('all from the conversation')—with no mention of scheduling, triggers, or autonomous background execution. No evidence of cron-like jobs, event-driven automations, or persistent agent workers running without human interaction.

   • [claimed-docs] “Connect your AI agent to Typesense Cloud and it can create and configure clusters, build collections, index your data, tune search and read …”
   • [claimed-docs] “Natural Language Search ... Typesense for AI Agents”

   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 drawn
   Typesense—none0/10

   Evidence shows Typesense exposes an MCP server so external AI agents can control Typesense Cloud (create clusters, index data, tune search) and supports Natural Language Search/RAG for querying data, but there is no evidence of a built-in AI assistant embedded within the Typesense product itself that a user delegates tasks to — the direction is Typesense being controlled by external agents, not an assistant inside the product.

   • [claimed-docs] “Connect your AI agent to Typesense Cloud and it can create and configure clusters, build collections, index your data, tune search and read …”
   • [claimed-docs] “Natural Language Search ... Typesense for AI Agents”
   • [claimed-docs] “It also offers native integrations with LLMs of your choice to enable Natural Language Search and built-in retrieval-augmented generation (R…”

   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 to Typesense
   Typesense✓fullclaimed7/10

   Typesense documents built-in Natural Language Search and native LLM integrations for RAG, plus a dedicated MCP server that lets an AI agent create/configure clusters, build collections, index data, and tune search 'all from the conversation' — directly enabling natural-language operation of both search and admin tasks. Missing for 10: independent/hands-on validation of natural-language search accuracy and community confirmation that the MCP-driven conversational admin flow works reliably in practice.

   • [claimed-docs] “Natural Language Search ... Typesense for AI Agents”
   • [claimed-docs] “It also offers native integrations with LLMs of your choice to enable Natural Language Search and built-in retrieval-augmented generation (R…”
   • [claimed-docs] “Connect your AI agent to Typesense Cloud and it can create and configure clusters, build collections, index your data, tune search and read …”

   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
   Typesense—none0/10

   While Typesense has API documentation pages (e.g. curation.html referenced in docs-45), there is no evidence of an interactive, runnable API reference (like a Swagger/OpenAPI playground). The probe explicitly found no OpenAPI spec at any standard path (404s), and no evidence describes embedded runnable code samples or a live API console.

   • [claimed-docs] “Copy Markdown”
   • [probe] “PROBE openapi: all candidate paths 404 (https://typesense.org/openapi.json, https://typesense.org/swagger.json, https://typesense.org/api/op…”

   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
   Typesense—none0/10

   The evidence pack shows an explicit probe for OpenAPI/swagger specs at typical locations returning 404 across all candidate paths, and no first-party documentation elsewhere claims a downloadable machine-readable API spec (only human-readable API reference docs and an llms.txt for markdown docs are mentioned).

   • [probe] “PROBE openapi: all candidate paths 404 (https://typesense.org/openapi.json, https://typesense.org/swagger.json, https://typesense.org/api/op…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://typesense.org/llms.txt # Typesense > Typesense is an open source search engine for developers and AI ag…”

   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
   Typesense—none0/10

   The evidence shows self-hosting options, testing guidance (Testcontainers, GitHub Actions), and an MCP server that lets agents manage real Typesense Cloud clusters, but nothing documents a dedicated sandbox/staging environment isolated from production data for testing purposes.

   • [claimed-docs] “Running Tests with Testcontainers ... Running Tests in Github Actions”
   • [claimed-docs] “Connect your AI agent to Typesense Cloud and it can create and configure clusters, build collections, index your data, tune search and read …”

   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
   Typesense—none0/10

   Evidence shows only a 'latest' docs path and no OpenAPI spec found (404s across candidate paths), with no documented API versioning scheme or deprecation policy anywhere in the pack. Missing for 10: explicit API version numbers, a published deprecation/sunset policy, and migration guides between versions.

   • [claimed-docs] “Copy Markdown”
   • [probe] “PROBE openapi: all candidate paths 404 (https://typesense.org/openapi.json, https://typesense.org/swagger.json, https://typesense.org/api/op…”

   proof ↗⚑ 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
   Typesense~partialclaimed7/10

   Typesense docs reference built-in Semantic Search, vector/hybrid search, and Cloud-side 'GPU Acceleration for embedding generation,' plus native LLM integrations for NLS/RAG, indicating documents/queries can be auto-vectorized without a separate embedding pipeline. However, the evidence pack lacks detail on which specific built-in models or third-party embedder integrations (e.g., OpenAI) are supported and has no independent/hands-on confirmation of this workflow. Missing for 10: detailed docs enumerating built-in vs external embedder options, and independent verification of the auto-embedding feature working end-to-end.

   • [claimed-docs] “Semantic Search”
   • [claimed-docs] “GPU Acceleration Use GPUs for embedding generation”
   • [claimed-docs] “Typesense combines typo-tolerant keyword search with direct vector search, hybrid search, semantic search, and geo search.”
   • [claimed-docs] “It also offers native integrations with LLMs of your choice to enable Natural Language Search and built-in retrieval-augmented generation (R…”

   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 to Elasticsearch
   Typesense✓fullclaimed8/10

   Typesense explicitly documents hybrid search combining vector similarity and keyword matching ('Typesense combines typo-tolerant keyword search with direct vector search, hybrid search, semantic search, and geo search'), with a dedicated 'Semantic Search' guide section and a public demo app explicitly labeled 'Semantic / Hybrid search on 300K HN comments'. Missing for 10: independent hands-on benchmarking of hybrid fusion quality/relevance beyond vendor docs and demo links.

   • [claimed-docs] “Typesense combines typo-tolerant keyword search with direct vector search, hybrid search, semantic search, and geo search.”
   • [claimed-docs] “Semantic Search”
   • [github] “Semantic / Hybrid search on 300K HN comments: hn-comments-search.typesense.org”

   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
   Typesense~partialclaimed6/10

   Typesense explicitly documents built-in RAG and Natural Language Search features ('native integrations with LLMs... built-in retrieval-augmented generation (RAG)', a dedicated 'Typesense for AI Agents' guide section) plus semantic/hybrid search support. However, the evidence pack lacks concrete API reference details (endpoints, request/response schemas) for the RAG/answer APIs and has no independent hands-on corroboration of these RAG capabilities working in practice. Missing for 10: detailed API/conversation endpoint documentation, independent developer validation of RAG output quality.

   • [claimed-docs] “Natural Language Search ... Typesense for AI Agents”
   • [claimed-docs] “Typesense is more battle-tested in high-scale production environments, and includes automatic Raft leader election in its open-source server…”
   • [claimed-docs] “It also offers native integrations with LLMs of your choice to enable Natural Language Search and built-in retrieval-augmented generation (R…”
   • [claimed-docs] “Semantic Search”

   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 Typesense
   Typesense~partialclaimed6/10

   Typesense docs describe pushing data from a primary database or CSV/JSON files into collections, and public demos index millions of records (2.2M recipes, 32M songs) showing bulk ingestion is a core supported workflow. However, the evidence pack lacks explicit documentation of a bulk import/export API (batch create/update/delete endpoints), rate-limit behavior at scale, or AI-agent-specific tooling for issuing bulk operations. missing for 10: explicit bulk import/export API docs, batch update/delete semantics, and evidence of AI-agent-driven bulk operation workflows.

   • [claimed-docs] “you'd push data that you already have - in your primary database (or CSV/JSON file) or you've crawled using a scraper - into Typesense”
   • [claimed-docs] “you'd push data that you already have - in your primary database (or CSV/JSON file) or you've crawled using a scraper - into Typesense and t…”
   • [claimed-docs] “Creating a "books" collection ... Adding books to the collection ... Searching for books ... Filtering results ... Faceting”
   • [claimed-docs] “Found 63 recipes out of 2,231,142 in ...ms”
   • [github] “Search a 32M songs dataset from MusicBrainz: songs-search.typesense.org”
   • [github] “Semantic / Hybrid search on 300K HN comments: hn-comments-search.typesense.org”

   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 to Typesense
   Typesense~partialclaimed4/10

   Typesense's curation/ranking system lets you define rules (e.g., pinning, hiding, promoting, boosting/burying results) that automatically trigger when certain query conditions are met, which is a narrow form of rule-based automation tied to search-time events. However, there is no evidence of a general event-driven automation engine (e.g., triggers on data changes, webhooks, scheduled actions) beyond search-query curation. Missing for 10: broader event types (data ingestion, index changes, external triggers), documented action types beyond result ranking/merchandising, and any workflow/automation API outside search curation.

   • [claimed-docs] “Boosting / Burying sets of records ... Promoting or Hiding Results (Merchandising) ... Tuning Typo Tolerance”
   • [claimed-docs] “Promoting or Hiding Results (Merchandising)”
   • [claimed-docs] “Boosting / Burying sets of records”
   • [claimed-docs] “Copy Markdown”

   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
   Typesense—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 Typesense
   Typesense✓fullclaimed7/10

   Docs explicitly walk through creating a collection, adding documents, searching, filtering, and faceting as a guided quickstart, plus install instructions across many platforms (Docker, Homebrew, binaries) to get started fast. However, there's no independent/hands-on confirmation of how quickly this can actually be completed, and community commentary focuses on other aspects (memory usage, comparisons) rather than onboarding speed. Missing for 10: independent timing/hands-on validation of the 'minutes' claim, community testimonials specifically about first-search experience.

   • [claimed-docs] “Creating a "books" collection ... Adding books to the collection ... Searching for books ... Filtering results ... Faceting”
   • [claimed-docs] “Creating a "books" collection”
   • [claimed-docs] “Filtering results”
   • [claimed-docs] “Docker, Docker Compose, Kubernetes, Mac via Homebrew, Mac Binary, DEB package on Ubuntu/Debian, RPM package on CentOS/RHEL, Linux Binary”
   • [claimed-docs] “Docker Docker Compose Kubernetes Mac via Homebrew Mac Binary DEB package on Ubuntu/Debian RPM package on CentOS/RHEL Linux Binary Windows (W…”

   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
   Typesense—none0/10

   The evidence pack contains no documentation, GitHub, or community references to official SDKs for JavaScript, Python, PHP, Ruby, Go, or other languages, nor any mention of SDK maintenance cadence. One community comment even suggests Typesense's Ruby/Rails integration lags a competitor's, but there is no confirmation of an official SDK ecosystem at all in the provided evidence.

   • [community] “I love Jason Bosco (the typesense guy). I love Ruby on Rails. But I've been using Meilisearch more and more over the past year on client pro…”

   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 Typesense
   Typesense~partialclaimed5/10

   Typesense's install docs list a 'Search UI Components' section, indicating an official UI library ecosystem exists, but the evidence pack gives no detail on what components are provided (search box, results list, facets, pagination) or how they compose into a full interface. Missing for 10: concrete documentation of specific component names/APIs (e.g., InstantSearch adapter, React/Vue components), code examples assembling a full search UI, and independent/hands-on confirmation that these components work end-to-end.

   • [claimed-docs] “Search UI Components”

   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 drawn
   Typesense—none0/10

   Docs explicitly describe pushing data you already have or 'crawled using a scraper' into Typesense, meaning founders must build or bring their own scraper/pipeline rather than use an official Typesense-branded crawler or connector like Algolia's Crawler or Elastic connectors; no such official tool is mentioned anywhere in the evidence.

   • [claimed-docs] “you'd push data that you already have - in your primary database (or CSV/JSON file) or you've crawled using a scraper - into Typesense”
   • [claimed-docs] “you'd push data that you already have - in your primary database (or CSV/JSON file) or you've crawled using a scraper - into Typesense and t…”

   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 Typesense
   Typesense~partialclaimed4/10

   Evidence confirms Typesense supports pushing/importing bulk data at large scale (millions of records, e.g. 2.2M recipes, 32M songs dataset) and provides indexing/search functionality, but there is no evidence of an async task-tracking mechanism (e.g. job IDs, polling for import completion status) that platform engineers could use to monitor long-running bulk imports. Missing for 10: documentation of async import job status/tracking API, evidence of import progress polling, and any independent benchmark of import throughput at scale.

   • [claimed-docs] “you'd push data that you already have - in your primary database (or CSV/JSON file) or you've crawled using a scraper - into Typesense”
   • [claimed-docs] “Found 63 recipes out of 2,231,142 in ...ms”
   • [github] “Search a 32M songs dataset from MusicBrainz: songs-search.typesense.org”
   • [claimed-docs] “you'd push data that you already have - in your primary database (or CSV/JSON file) or you've crawled using a scraper - into Typesense and t…”
   • [claimed-docs] “Creating a "books" collection ... Adding books to the collection ... Searching for books ... Filtering results ... Faceting”

   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
   Typesense~partialclaimed4/10

   Docs show a document-add workflow ('Adding books to the collection') and instant sub-50ms search claims, implying documents become searchable quickly after being pushed, but the evidence pack never explicitly documents update/delete operations, incremental indexing mechanics, or benchmarks showing changes are searchable in near real time without full reindex. Missing for 10: explicit docs/benchmarks on document update and delete APIs, confirmation of incremental (non-full-reindex) indexing, and independent verification of update/delete latency.

   • [claimed-docs] “Creating a "books" collection ... Adding books to the collection ... Searching for books ... Filtering results ... Faceting”
   • [claimed-docs] “Creating a "books" collection”
   • [claimed-docs] “Typesense is an open-source, typo-tolerant search engine optimized for instant (typically sub-50ms) search-as-you-type experiences and devel…”
   • [claimed-docs] “you'd push data that you already have - in your primary database (or CSV/JSON file) or you've crawled using a scraper - into Typesense”

   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 Typesense
   Typesense~partialprobed6/10

   Typesense is fundamentally API-first: collections, indexing, search, filtering, faceting, ranking, curation, and even cluster management (via Typesense Cloud API/MCP) are documented as API operations, and the product ships without a mandatory admin UI, implying the API is the primary/complete interface. However, the evidence pack lacks a direct statement enumerating UI-only features and confirming 1:1 parity, and there's no OpenAPI spec discoverable (probe shows 404s), which weakens verifiable completeness. Missing for 10: an explicit UI feature inventory compared against API capabilities, a published OpenAPI/spec artifact, and independent confirmation that no admin/dashboard-only actions exist outside the API.

   • [claimed-docs] “Creating a "books" collection ... Adding books to the collection ... Searching for books ... Filtering results ... Faceting”
   • [claimed-docs] “Filtering results”
   • [claimed-docs] “Promoting or Hiding Results (Merchandising)”
   • [claimed-docs] “Boosting / Burying sets of records”
   • [claimed-docs] “Connect your AI agent to Typesense Cloud and it can create and configure clusters, build collections, index your data, tune search and read …”
   • [probe] “PROBE openapi: all candidate paths 404 (https://typesense.org/openapi.json, https://typesense.org/swagger.json, https://typesense.org/api/op…”
   • [claimed-docs] “Typesense **Cloud** is the hosted SaaS version of our **Open Source** product.”

   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 to Typesense
   Typesense~partialclaimed4/10

   Typesense is documented as fully open-source and self-hostable (Docker, binaries, Homebrew, etc.), which supports the ability to run your own instance and avoid lock-in, and migration guides exist for moving *into* Typesense from Postgres/Algolia. However, the evidence pack contains no explicit documentation of a bulk data export feature/API or an open interchange format (e.g., JSONL) for extracting your indexed data back out. missing for 10: explicit documentation of a data export API/CLI command, confirmation of an open export format (JSON/JSONL), and any guide on migrating *away from* Typesense to another system.

   • [claimed-docs] “An open source alternative to Algolia, with some key quirks solved”
   • [claimed-docs] “Typesense is an open source search engine that can be downloaded and run from your computer locally or from any server.”
   • [claimed-docs] “Docker, Docker Compose, Kubernetes, Mac via Homebrew, Mac Binary, DEB package on Ubuntu/Debian, RPM package on CentOS/RHEL, Linux Binary”
   • [claimed-docs] “Migrating from Postgres for Full-Text Search”
   • [claimed-docs] “Migrating from Algolia”

   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 to Typesense
   Typesense✓fullprobed8/10

   Typesense is repeatedly documented and confirmed via GitHub/community as an open-source project (GPL-3.0 style OSS repo with public source), with docs explicitly stating 'open source search engine' and code publicly hosted and inspected by a community member ('written in C++, code is simple enough to skim'). missing for 10: explicit license name/text citation and a first-party statement of the specific OSI license terms.

   • [claimed-docs] “Typesense is an open-source, typo-tolerant search engine optimized for instant (typically sub-50ms) search-as-you-type experiences and devel…”
   • [github] “An Open Source Algolia Alternative & An Easier-to-Use ElasticSearch Alternative”
   • [claimed-docs] “Typesense is an open source search engine that can be downloaded and run from your computer locally or from any server.”
   • [community] “It's written in C++, and the code is simple enough to skim. I would expect this to be some hefty Java thing.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://typesense.org/llms.txt # Typesense > Typesense is an open source search engine for developers and AI ag…”

   proof ↗⚑ 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 Typesense
   Typesense✓fullcommunity9/10

   Typesense is explicitly open source and provides extensive self-hosting install paths (Docker, Docker Compose, Kubernetes, Homebrew, DEB/RPM packages, Linux binaries, Terraform module) plus a downloads page stating it 'can be downloaded and run from your computer locally or from any server,' distinct from the separately offered hosted Cloud SaaS. Community comments corroborate real-world self-hosted deployments (memory footprint, running in docker-compose). Missing for 10: independent hands-on production self-hosting case studies at scale and more detail on self-hosted operational parity with Cloud features.

   • [claimed-docs] “Docker, Docker Compose, Kubernetes, Mac via Homebrew, Mac Binary, DEB package on Ubuntu/Debian, RPM package on CentOS/RHEL, Linux Binary”
   • [claimed-docs] “Docker Docker Compose Kubernetes Mac via Homebrew Mac Binary DEB package on Ubuntu/Debian RPM package on CentOS/RHEL Linux Binary Windows (W…”
   • [claimed-docs] “Docker Compose Kubernetes Mac via Homebrew Mac Binary DEB package on Ubuntu/Debian RPM package on CentOS/RHEL Linux Binary Windows (WSL) Ter…”
   • [claimed-docs] “Typesense is an open source search engine that can be downloaded and run from your computer locally or from any server.”
   • [claimed-docs] “Typesense **Cloud** is the hosted SaaS version of our **Open Source** product.”
   • [community] “good to know the memory efficiency !! when 1 million Hacker News titles are indexed along with their points, Typesense consumes 165 MB of me…”
   • [community] “I previously used Opensearch for my Rails project, it was quite heavy piece of service to run in the docker compose environment. I said to m…”

   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 drawn
   Typesense—none0/10

   The evidence pack covers installation, ranking/relevance tuning, production best practices, and monitoring, but contains no mention of built-in analytics dashboards for top queries, no-result queries, or click-through tracking. This is a fair capability to expect from a search engine product, so absence of evidence yields 'none' rather than 'na'.

   • [claimed-docs] “Production Best Practices ... Configuration ... Monitoring ... Search Relevance ... Security ... Schema Management”
   • [claimed-docs] “Production Best Practices ... Monitoring ... Search Relevance ... Security ... Schema Management”
   • [claimed-docs] “Production Best Practices”

   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
   Typesense~partialcommunity5/10

   Typesense docs mention built-in high availability, automatic Raft leader election, Kubernetes/Docker Swarm deployment, and a 'Production Best Practices' guide, plus a Cloud tier with dedicated clusters and HA add-ons — suggesting a genuine clustering/HA story. However, there's no documented scaling playbook that walks from prototype to hundreds of millions of documents (sharding strategy, replica scaling guidance, capacity benchmarks at that scale), and demo datasets shown top out around 32M records. A community comment even flags that Elasticsearch is seen as better suited when you 'want to store billions of documents,' and another worries about memory-hog scaling — concrete caveats rather than full confidence. Missing for 10: documented multi-hundred-million-doc scaling benchmarks/case studies, explicit sharding guidance, and stronger independent corroboration of HA/clustering at that scale.

   • [claimed-docs] “High Availability Recommended for Production Envs”
   • [claimed-docs] “Typesense includes built-in high availability and the freedom to self-host or use a dedicated Typesense Cloud cluster.”
   • [claimed-docs] “Typesense is more battle-tested in high-scale production environments, and includes automatic Raft leader election in its open-source server…”
   • [claimed-docs] “Typesense is more battle-tested in high-scale production environments, and includes automatic Raft leader election in its open-source server”
   • [claimed-docs] “You get a dedicated cluster, with no limits on records or operations.”
   • [claimed-docs] “Production Best Practices ... Configuration ... Monitoring ... Search Relevance ... Security ... Schema Management”
   • [github] “Search a 32M songs dataset from MusicBrainz: songs-search.typesense.org”
   • [community] “Storing everything in memory seems fast, but seems like it'd be quite the resource hog on a server -- is that a normal approach to take? ...…”
   • [community] “We wanted a simple search engine that was fast, handled typographic errors out-of-the-box and was also simple to run and manage... Elasticse…”

   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 Typesense
   Typesense✓fullclaimed8/10

   Typesense is explicitly open-source and self-hostable via Docker, Docker Compose, Kubernetes, Homebrew, binaries, DEB/RPM packages, and Terraform modules, with the same core feature set (search, filtering, faceting, ranking, semantic/hybrid search) documented for self-hosted use, and Typesense Cloud is described as 'the hosted SaaS version of our Open Source product,' implying feature parity. missing for 10: independent/hands-on confirmation that self-hosted clusters achieve full parity with Cloud-only operational features (e.g., Search Delivery Network, GPU acceleration, HA tooling) rather than just vendor claims.

   • [claimed-docs] “Docker, Docker Compose, Kubernetes, Mac via Homebrew, Mac Binary, DEB package on Ubuntu/Debian, RPM package on CentOS/RHEL, Linux Binary”
   • [claimed-docs] “Terraform Module”
   • [claimed-docs] “Typesense **Cloud** is the hosted SaaS version of our **Open Source** product.”
   • [claimed-docs] “Typesense is an open source search engine that can be downloaded and run from your computer locally or from any server.”
   • [claimed-docs] “Typesense includes built-in high availability and the freedom to self-host or use a dedicated Typesense Cloud cluster.”
   • [claimed-docs] “Production Best Practices ... Configuration ... Monitoring ... Search Relevance ... Security ... Schema Management”
   • [claimed-docs] “High Availability Recommended for Production Envs”
   • [claimed-docs] “GPU Acceleration Use GPUs for embedding generation”

   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 Typesense
   Typesense~partialclaimed6/10

   Typesense Cloud pricing is based on dedicated cluster resources with 'no limits on records or operations' rather than per-request metering, and the open-source self-host option lets founders avoid cloud billing entirely, both of which support predictable, non-cliff cost growth. However, there's no independent evidence or founder testimony validating actual cost predictability at scale, and no detail on how cluster upgrade/resizing costs behave as usage grows. Missing for 10: independent case studies of cost scaling, detail on tier-upgrade pricing mechanics, and community confirmation of no surprise billing.

   • [claimed-docs] “Typesense **Cloud** is the hosted SaaS version of our **Open Source** product.”
   • [claimed-docs] “You get a dedicated cluster, with no limits on records or operations.”
   • [claimed-docs] “Typesense is an open source search engine that can be downloaded and run from your computer locally or from any server.”

   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 to Typesense
   Typesense~partialclaimed4/10

   Typesense Cloud has a public pricing calculator page referencing dedicated clusters, HA, GPU acceleration, and SDN features, implying some cost transparency, but the evidence never shows actual published per-unit rates (e.g., $/search, $/record, $/node) that a founder could use to predict costs precisely. missing for 10: explicit published unit prices, cost breakdown examples, self-host vs cloud cost comparison, independent confirmation that the calculator yields predictable pricing.

   • [claimed-docs] “Typesense **Cloud** is the hosted SaaS version of our **Open Source** product.”
   • [claimed-docs] “You get a dedicated cluster, with no limits on records or operations.”
   • [claimed-docs] “Search Delivery Network Like a CDN, but for search”
   • [claimed-docs] “High Availability Recommended for Production Envs”
   • [claimed-docs] “GPU Acceleration Use GPUs for embedding generation”

   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 Typesense
   Typesense~partialclaimed6/10

   Typesense is open-source and explicitly self-hostable ('run from your computer locally or from any server', 'freedom to self-host or use a dedicated Typesense Cloud cluster'), which lets an AI-native user fully control where data physically resides by choosing their own hosting location. However, there is no evidence of an explicit region/data-residency selector or documented list of Typesense Cloud regions for users who prefer the managed SaaS option. Missing for 10: documented Typesense Cloud region selection UI/list, explicit data-residency/compliance statements (e.g., GDPR region guarantees).

   • [claimed-docs] “Typesense is an open source search engine that can be downloaded and run from your computer locally or from any server.”
   • [claimed-docs] “Typesense includes built-in high availability and the freedom to self-host or use a dedicated Typesense Cloud cluster.”
   • [claimed-docs] “Typesense **Cloud** is the hosted SaaS version of our **Open Source** product.”

   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
   Typesense—none0/10

   No evidence pack citation documents data retention or deletion controls (e.g., TTL policies, document/collection deletion APIs, data export/purge tools) for Typesense; the pack only covers indexing, ranking, install options, and cloud pricing. Since Typesense is a data store for search, deletion/retention controls are a fair axis, but the evidence provides none.

   ⚑ 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
   Typesense—none0/10

   No evidence pack item mentions telemetry, usage tracking, or an opt-out mechanism; Typesense is self-hostable open source, but no explicit privacy/telemetry documentation is provided here.

   ⚑ 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 Typesense
   Typesense✓fullclaimed8/10

   Typesense docs explicitly cover a dedicated Ranking & Relevance guide with sections on Boosting/Burying sets of records, Promoting or Hiding Results (Merchandising), and a dedicated Curation API endpoint for pinning/hiding specific hits per query, plus synonyms are a standard documented feature referenced within the relevance-tuning guide set. Missing for 10: independent hands-on developer accounts specifically validating curation/pinning behavior in production, and no direct synonym-API citation in the pack (only implied via ranking-and-relevance guide).

   • [claimed-docs] “Boosting / Burying sets of records ... Promoting or Hiding Results (Merchandising) ... Tuning Typo Tolerance”
   • [claimed-docs] “Promoting or Hiding Results (Merchandising)”
   • [claimed-docs] “Boosting / Burying sets of records”
   • [claimed-docs] “Copy Markdown”

   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 Typesense
   Typesense✓fullcommunity8/10

   Typesense docs explicitly cover boosting/burying, promoting/hiding (curation), ranking based on relevance+popularity, ranking based on relevance+recency, and text match score tuning, and a default_sorting_field mechanism lets any numeric business signal (popularity, recency, margin, etc.) be blended with textual relevance — corroborated by a community post confirming the default_sorting_field behavior in practice. Missing for 10: no independent hands-on benchmark specifically testing margin/business-metric ranking, and no third-party review validating complex multi-signal tuning at scale.

   • [claimed-docs] “Boosting / Burying sets of records ... Promoting or Hiding Results (Merchandising) ... Tuning Typo Tolerance”
   • [claimed-docs] “Ranking based on Relevance and Popularity ... Ranking based on Relevance and Recency”
   • [claimed-docs] “Promoting or Hiding Results (Merchandising)”
   • [claimed-docs] “Boosting / Burying sets of records”
   • [claimed-docs] “Ranking based on Relevance and Popularity”
   • [claimed-docs] “Text Match Score & Type”
   • [community] “Typesense use a default_sorting_field on each document, meaning before indexing you need to compute a relevancy score for Typesense to sort …”

   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 to Typesense
   Typesense~partialclaimed5/10

   Typesense docs reference a 'Text Match Score & Type' feature in the ranking-and-relevance guide, indicating some visibility into how text matching contributed to a result's rank, but there is no evidence of a full explain-style breakdown covering all ranking factors (popularity, recency, custom boosts) or independent confirmation of its usefulness for debugging rank order. missing for 10: full ranking explanation covering all scoring factors (boosts, sort_by fields, popularity), hands-on/independent validation of the explain feature's usefulness for platform engineers.

   • [claimed-docs] “Text Match Score & Type”
   • [claimed-docs] “Boosting / Burying sets of records ... Promoting or Hiding Results (Merchandising) ... Tuning Typo Tolerance”
   • [claimed-docs] “Ranking based on Relevance and Popularity ... Ranking based on Relevance and Recency”

   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 drawn
   Typesense—none0/10

   Evidence shows Typesense supports fast search-as-you-type and typo-tolerant querying, but there is no documentation of a dedicated suggestions/autocomplete feature driven by search-traffic analytics or a separate suggestions index (unlike Algolia's Query Suggestions). Curation/promotion features (typesense-docs-45, docs-27/28) address merchandising, not traffic-based suggestion indexing.

   ⚑ 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 Typesense
   Typesense✓fullcommunity9/10

   Typesense's docs explicitly position it as optimized for sub-50ms search-as-you-type experiences with typo tolerance, and this is corroborated by community praise for instant search/fuzzy matching and demos (e.g., 32M song dataset search) and the live search-with-latency example on typesense.org showing millisecond result counts. Independent HN commenters confirm real-world instant-search behavior and performance characteristics (memory/speed tradeoffs), reinforcing the vendor claims. Missing for 10: independently benchmarked keystroke-level latency numbers from a third party beyond anecdotal community praise.

   • [claimed-docs] “optimized for instant (typically sub-50ms) search-as-you-type experiences and developer productivity”
   • [claimed-docs] “Typesense is an open-source, typo-tolerant search engine optimized for instant (typically sub-50ms) search-as-you-type experiences and devel…”
   • [claimed-docs] “Found 63 recipes out of 2,231,142 in ...ms”
   • [github] “Search a 32M songs dataset from MusicBrainz: songs-search.typesense.org”
   • [community] “Congrats on shipping! Love the instant search queries and the fuzzy text matching.”
   • [community] “I'm going to give Typesense a try today... went from Meilisearch (which is great) to Elastic for some more complex aggregation queries but t…”

   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 Typesense
   Typesense✓fullcommunity8/10

   Typesense is documented as 'typo-tolerant search engine' out-of-the-box, and docs include a dedicated 'Tuning Typo Tolerance' section for controlling fuzzy matching behavior, plus community feedback praising built-in fuzzy text matching. missing for 10: no independent benchmark of typo-tolerance accuracy/edge-cases and no detail in evidence on exact configurable parameters (num_typos, per-field settings) beyond the section title.

   • [claimed-docs] “Typesense is an open-source, typo-tolerant search engine optimized for instant (typically sub-50ms) search-as-you-type experiences and devel…”
   • [claimed-docs] “Boosting / Burying sets of records ... Promoting or Hiding Results (Merchandising) ... Tuning Typo Tolerance”
   • [community] “Congrats on shipping! Love the instant search queries and the fuzzy text matching.”
   • [community] “We wanted a simple search engine that was fast, handled typographic errors out-of-the-box and was also simple to run and manage... Elasticse…”

   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 Typesense
   Typesense✓fullcommunity7/10

   Typesense's official docs walk through building faceted search ("Faceting" step alongside "Filtering results" in the same query workflow), and community commentary independently confirms it "handles faceted search already," supporting single-query filter+facet delivery. Missing for 10: explicit documentation/example of range facets and live facet counts syntax, and independent hands-on verification of facet count accuracy at scale.

   • [claimed-docs] “Creating a "books" collection ... Adding books to the collection ... Searching for books ... Filtering results ... Faceting”
   • [claimed-docs] “Filtering results”
   • [community] “As of now, my project uses ElasticSearch — it works fine, but it wants lots of RAM which I find slightly annoying... I suggest you use Types…”

   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 drawn
   Typesense—none0/10

   The evidence pack only references a generic 'Security' doc heading without any mention of scoped/tenant API keys, per-user search restrictions, or multitenancy mechanisms. Missing for 10: any mention of scoped search API keys, tenant-based filtering, or documentation on restricting a token's search scope to a subset of documents.

   • [claimed-docs] “Production Best Practices ... Configuration ... Monitoring ... Search Relevance ... Security ... Schema Management”
   • [claimed-docs] “Production Best Practices ... Monitoring ... Search Relevance ... Security ... Schema Management”

   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