Elasticsearch vs Orama

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
   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

   Orama~partialprobed6/10

   Orama's JS/TS (and Python/Rust) APIs clearly support end-to-end create→insert→search workflows (orama-docs-1,2,15,16,24,32), and Orama Cloud ships an auto-configured MCP server for interacting with project data from AI clients like Cursor (orama-docs-9,20,30, orama-probe-3), satisfying the 'no dashboard' requirement for search/query. However, there's no evidence of a CLI, and the MCP server's documented scope emphasizes querying/interacting with existing data rather than confirmed index-creation or document-insertion operations, and OpenAPI/REST API docs could not be located (orama-probe-2). Missing for 10: dedicated CLI tool, explicit confirmation MCP server supports index creation and document insertion (not just querying), and a public REST/OpenAPI spec.

   • [claimed-docs] “Since version `1.2.0`, Orama supports vector search.”
   • [claimed-docs] “insertion in Orama is quick and intuitive”
   • [claimed-docs] “We can create a new instance (from now on database) with an **indexing `schema`**.”
   • [claimed-docs] “Inserting a large number of documents in a loop could potentially block the event loop. Instead `insertMultiple` handles this case better.”
   • [claimed-docs] “you'll be able to interact with your data from different AI interfaces, including ChatGPT, Cursor, and many other”
   • [claimed-docs] “Every Orama Cloud project comes with an MCP server that is automatically configured to interact with your project's data.”
   • [claimed-docs] “you'll be able to interact with your data from different AI interfaces, including ChatGPT, Cursor, and many other.”
   • [probe] “official MCP server documented at https://docs.orama.com/docs/cloud/mcp-server”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.orama.com/openapi.json, https://docs.orama.com/swagger.json, https://docs.orama.com/api…”
   • [claimed-docs] “Orama Cloud officially supports the following SDKs: - JavaScript/TypeScript - Python - Rust”

   proof ↗⚑ flag

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

   weight 2 · round to Orama
   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

   Orama✓fullprobed8/10

   Orama Cloud ships an official, automatically-configured MCP server per project that lets AI interfaces (ChatGPT, Cursor, etc.) interact with indexed data, confirmed both in docs and via a live probe of the docs page. Missing for 10: independent/hands-on evidence of the MCP server's tool surface covering analytics and index-management operations (docs emphasize query/interaction but don't detail full CRUD/analytics tool coverage), and no third-party confirmation of real-world usage.

   • [claimed-docs] “you'll be able to interact with your data from different AI interfaces, including ChatGPT, Cursor, and many other”
   • [claimed-docs] “Every Orama Cloud project comes with an MCP server that is automatically configured to interact with your project's data.”
   • [claimed-docs] “you'll be able to interact with your data from different AI interfaces, including ChatGPT, Cursor, and many other.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.orama.com/llms.txt # Docs ## cloud - [Introduction to Orama Cloud](/docs/cloud): Run Orama at sca…”
   • [probe] “official MCP server documented at https://docs.orama.com/docs/cloud/mcp-server”

   proof ↗⚑ flag

Agent access

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

   weight 2 · round to Orama
   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

   Orama✓fullprobed8/10

   Orama has a live llms.txt (HTTP 200) plus a full llms-full.txt content reference, confirmed by direct probe, and docs are structured for agent consumption. missing for 10: no independent/third-party confirmation that agents actually consume this successfully, and no explicit agent-onboarding guide beyond the llms.txt file itself.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.orama.com/llms.txt # Docs ## cloud - [Introduction to Orama Cloud](/docs/cloud): Run Orama at sca…”
   • [claimed-docs] “A data source identifies a specific set of documents, ideally coming from a single origin.”
   • [claimed-docs] “you can put data that will be updated frequently in a single data source (let's call it `docs`), and put data that follows a different updat…”
   • [claimed-docs] “A project is a set of **data sources** that you want to use for RAG, search, or any other method of retrieval.”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   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

   Orama~partialclaimed6/10

   Orama ships as a JS/TS (and Rust/Python SDK) library with programmatic insert/search APIs and no UI dependency, meaning it can be embedded and run headlessly in scripts, servers, or automation pipelines (e.g. orama-docs-2, orama-docs-15, orama-docs-21). However, there is no explicit documentation of CI-specific workflows, CLI tooling, or headless automation examples. Missing for 10: explicit CI/CD integration guides, a dedicated CLI for automation, and independent evidence of headless CI usage.

   • [claimed-docs] “insertion in Orama is quick and intuitive”
   • [claimed-docs] “We can create a new instance (from now on database) with an **indexing `schema`**.”
   • [claimed-docs] “Orama Cloud officially supports the following SDKs: - JavaScript/TypeScript - Python - Rust”
   • [claimed-docs] “If you have a lot of records, we suggest using the `insertMultiple` function”
   • [claimed-docs] “The open-source search library. Add fast, relevant search to your own application at no cost.”

   proof ↗⚑ flag

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

   weight 3 · round to Orama
   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

   Orama✓fullprobed8/10

   Orama Cloud ships an official, automatically-configured MCP server per project, documented and confirmed via probe, enabling agents like ChatGPT and Cursor to connect to project data. Missing for 10: independent/hands-on third-party corroboration beyond vendor docs and probe confirmation.

   • [claimed-docs] “you'll be able to interact with your data from different AI interfaces, including ChatGPT, Cursor, and many other”
   • [claimed-docs] “Every Orama Cloud project comes with an MCP server that is automatically configured to interact with your project's data.”
   • [claimed-docs] “you'll be able to interact with your data from different AI interfaces, including ChatGPT, Cursor, and many other.”
   • [probe] “official MCP server documented at https://docs.orama.com/docs/cloud/mcp-server”

   proof ↗⚑ flag

4. ai-native userUse an official CLI

   weight 2 · round drawn
   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

   Orama—none0/10

   Evidence covers SDKs (JS/TS, Python, Rust), an MCP server, and search features, but there is no mention of an official CLI tool anywhere in the docs or GitHub evidence. Missing for 10: any documented CLI command/tool, installation instructions for a CLI, or CLI usage examples.

   ⚑ flag

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

   weight 3 · round drawn
   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

   Orama~partialprobed6/10

   Orama documents SDK APIs (JS/TS, Python, Rust), a documented MCP server for Orama Cloud, and llms.txt for AI consumption, showing a documented public API surface usable by AI-native workflows. However, a direct OpenAPI/REST spec probe returned 404 on all candidate paths, indicating no discoverable formal REST API spec despite SDK/MCP documentation. missing for 10: a public OpenAPI/REST spec, independent/hands-on confirmation of API usage by AI agents beyond docs, and details on API completeness for non-JS/Python/Rust clients.

   • [claimed-docs] “you'll be able to interact with your data from different AI interfaces, including ChatGPT, Cursor, and many other”
   • [claimed-docs] “Every Orama Cloud project comes with an MCP server that is automatically configured to interact with your project's data.”
   • [claimed-docs] “Orama Cloud officially supports the following SDKs: - JavaScript/TypeScript - Python - Rust”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.orama.com/llms.txt # Docs ## cloud - [Introduction to Orama Cloud](/docs/cloud): Run Orama at sca…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.orama.com/openapi.json, https://docs.orama.com/swagger.json, https://docs.orama.com/api…”
   • [probe] “official MCP server documented at https://docs.orama.com/docs/cloud/mcp-server”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   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

   Orama—none0/10

   The evidence pack shows no mention of issuing scoped or least-privilege API keys/credentials for agents — only generic API key proxying (Secure Proxy) to hide a key client-side, which is not the same as granular credential scoping. Missing for 10: any documentation of role-based or scoped API key generation, permission scopes, or agent-specific credential issuance.

   • [claimed-docs] “AnswerSession** that allows you to perform ChatGPT-like experiences on your website. It uses a free feature from Orama Cloud called **Secure…”

   proof ↗⚑ flag

7. ai-native userBuild against official SDKs

   weight 2 · round drawn
   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

   Orama✓fullprobed8/10

   Orama officially documents and supports SDKs for JavaScript/TypeScript, Python, and Rust for Orama Cloud, with APIs designed to closely mirror across Cloud and open-source, easing AI-native integration; it also ships an official MCP server for AI interface interoperability. missing for 10: independent/community verification of SDK quality beyond first-party docs, and no explicit versioned SDK changelog/compatibility matrix.

   • [claimed-docs] “Orama Cloud officially supports the following SDKs: - JavaScript/TypeScript - Python - Rust”
   • [claimed-docs] “The APIs are designed to be as close as possible to the **Orama Cloud** APIs, so you can easily migrate your projects from **Orama Cloud** t…”
   • [claimed-docs] “Every Orama Cloud project comes with an MCP server that is automatically configured to interact with your project's data.”
   • [claimed-docs] “you'll be able to interact with your data from different AI interfaces, including ChatGPT, Cursor, and many other”
   • [probe] “official MCP server documented at https://docs.orama.com/docs/cloud/mcp-server”

   proof ↗⚑ flag

8. ai-native userSubscribe to events via webhooks

   weight 2 · round drawn
   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

   Orama—none0/10

   No evidence of webhook subscription support anywhere in the docs or probes; Orama's event-driven integration is limited to an MCP server and SDKs, not webhooks.

   ⚑ flag

Agentic features

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

   weight 2 · round to Orama
   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

   Orama✓fullclaimed7/10

   Orama's AnswerSession feature explicitly delivers ChatGPT-like AI-generated answers with sources drawn from the user's own indexed data, and Orama Cloud extends this with AI-powered NLP search and RAG-oriented data sources/projects, directly matching the ask for in-product AI-generated insights. Missing for 10: independent/hands-on validation of answer quality, and no explicit evidence of proactive 'suggestions' beyond Q&A-style answers.

   • [claimed-docs] “turns a question into a straight answer with the sources behind it”
   • [claimed-docs] “AnswerSession** that allows you to perform ChatGPT-like experiences on your website. It uses a free feature from Orama Cloud called **Secure…”
   • [claimed-docs] “AnswerSession** that allows you to perform ChatGPT-like experiences on your website.”
   • [claimed-docs] “we introduced a new feature called **AnswerSession** that allows you to perform ChatGPT-like experiences on your website.”
   • [claimed-docs] “With Orama 3.0, we introduced a new feature called AnswerSession that allows you to perform ChatGPT-like experiences on your website.”
   • [claimed-docs] “Full-text search - Vector search - Hybrid search - AI-powered NLP search”
   • [claimed-docs] “A project is a set of **data sources** that you want to use for RAG, search, or any other method of retrieval.”
   • [claimed-docs] “A project is a set of data sources that you want to use for RAG, search, or any other method of retrieval.”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   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

   Orama—none0/10

   No evidence in the pack shows Orama offering scheduled tasks, triggers, or autonomous background automations; its documented features are search, indexing, vector/hybrid search, and an MCP server for interactive querying, not self-running automation workflows.

   ⚑ flag

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

   weight 3 · round to Orama
   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

   Orama~partialclaimed4/10

   Orama's 'AnswerSession'/Answer Engine feature provides a built-in, ChatGPT-like conversational AI assistant embedded directly in the product for querying data and getting answers with sources, which is a form of an in-product AI assistant. However, this is limited to answering questions over indexed data (RAG-style Q&A) rather than true task delegation — there's no evidence of the assistant performing multi-step actions, automations, or agentic workflows on the user's behalf. Missing for 10: evidence of task execution/automation capabilities beyond Q&A, evidence of the assistant taking actions (not just answering), and independent/hands-on validation of the assistant's real-world behavior.

   • [claimed-docs] “allows you to perform ChatGPT-like experiences on your website”
   • [claimed-docs] “AnswerSession** that allows you to perform ChatGPT-like experiences on your website. It uses a free feature from Orama Cloud called **Secure…”
   • [claimed-docs] “AnswerSession** that allows you to perform ChatGPT-like experiences on your website.”
   • [claimed-docs] “we introduced a new feature called **AnswerSession** that allows you to perform ChatGPT-like experiences on your website.”
   • [claimed-docs] “With Orama 3.0, we introduced a new feature called AnswerSession that allows you to perform ChatGPT-like experiences on your website.”
   • [claimed-docs] “turns a question into a straight answer with the sources behind it”

   proof ↗⚑ flag

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

   weight 2 · round to Orama
   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

   Orama~partialprobed7/10

   Orama's AnswerSession lets end-users pose natural-language questions and get synthesized answers with sources (docs-6, docs-13, docs-18, docs-28, docs-35), and its MCP server exposes Orama Cloud project data to AI interfaces like ChatGPT and Cursor for natural-language interaction (docs-9, docs-20, docs-30, orama-probe-3). This covers natural-language querying/retrieval well, but there's no evidence of natural-language commands for administrative/configuration operations (schema creation, data source management, indexing) — those remain API/SDK driven. Missing for 10: evidence of NL-driven configuration or management actions beyond querying, and independent/hands-on confirmation of AnswerSession or MCP usage quality.

   • [claimed-docs] “allows you to perform ChatGPT-like experiences on your website”
   • [claimed-docs] “turns a question into a straight answer with the sources behind it”
   • [claimed-docs] “AnswerSession** that allows you to perform ChatGPT-like experiences on your website. It uses a free feature from Orama Cloud called **Secure…”
   • [claimed-docs] “we introduced a new feature called **AnswerSession** that allows you to perform ChatGPT-like experiences on your website.”
   • [claimed-docs] “With Orama 3.0, we introduced a new feature called AnswerSession that allows you to perform ChatGPT-like experiences on your website.”
   • [claimed-docs] “you'll be able to interact with your data from different AI interfaces, including ChatGPT, Cursor, and many other”
   • [claimed-docs] “Every Orama Cloud project comes with an MCP server that is automatically configured to interact with your project's data.”
   • [claimed-docs] “you'll be able to interact with your data from different AI interfaces, including ChatGPT, Cursor, and many other.”
   • [probe] “official MCP server documented at https://docs.orama.com/docs/cloud/mcp-server”

   proof ↗⚑ flag

Api quality

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

   weight 2 · round drawn
   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

   Orama—none0/10

   Evidence shows only static markdown documentation (create.mdx, insert.mdx, facets.mdx, etc.) with no mention of an interactive API reference or runnable code examples; a probe for OpenAPI/Swagger specs at docs.orama.com returned 404 on all candidate paths, indicating no interactive API explorer exists.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.orama.com/openapi.json, https://docs.orama.com/swagger.json, https://docs.orama.com/api…”
   • [claimed-docs] “A data source identifies a specific set of documents, ideally coming from a single origin.”
   • [claimed-docs] “Orama Cloud officially supports the following SDKs: - JavaScript/TypeScript - Python - Rust”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   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

   Orama—none0/10

   A direct probe found no OpenAPI/Swagger spec at any standard path (all 404s), and no documentation references a downloadable machine-readable API spec; only an llms.txt for docs discovery exists, which is not an API spec.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.orama.com/openapi.json, https://docs.orama.com/swagger.json, https://docs.orama.com/api…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.orama.com/llms.txt # Docs ## cloud - [Introduction to Orama Cloud](/docs/cloud): Run Orama at sca…”

   proof ↗⚑ flag

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

   weight 1 · round to Elasticsearch
   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

   Orama—none0/10

   No evidence of a sandbox/staging environment or test mode separate from production data; docs cover search features, MCP server, and cloud deployment but nothing about sandbox testing isolation.

   ⚑ flag

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

   weight 2 · round drawn
   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

   Orama—none0/10

   No evidence of API versioning scheme or a documented deprecation policy; version mentions (e.g., 1.2.0, 3.0) refer to product/feature releases, not API contract versioning. The OpenAPI probe even returned 404s, and no changelog or deprecation policy page is cited. Missing for 10: versioned API endpoints/spec, explicit deprecation policy/timeline documentation, changelog with breaking-change notices.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.orama.com/openapi.json, https://docs.orama.com/swagger.json, https://docs.orama.com/api…”
   • [claimed-docs] “Since version `1.2.0`, Orama supports vector search.”

   proof ↗⚑ 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
   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

   Orama~partialclaimed6/10

   Orama's official `plugin-embeddings` generates embeddings for documents automatically at insert and search time, letting developers add vector/hybrid search without building their own embedding pipeline [orama-docs-7], and Orama Cloud's Secure Proxy/AnswerSession similarly proxies embedding/LLM calls so API keys aren't exposed client-side [orama-docs-18]. However, the docs don't detail a fully built-in default embedder independent of an external provider (e.g., OpenAI) or give hands-on/independent proof of zero-setup vectorization. Missing for 10: details on a truly self-contained default embedding model vs. reliance on third-party API keys, and independent corroboration of the plugin's real-world use.

   • [claimed-docs] “This plugin generates embeddings for your documents at insert and search time, allowing you to perform vector and hybrid searches on your do…”
   • [claimed-docs] “AnswerSession** that allows you to perform ChatGPT-like experiences on your website. It uses a free feature from Orama Cloud called **Secure…”
   • [claimed-docs] “Hybrid search is an Orama feature that allows you to perform full-text and vector search in one unique query, combining the results to get t…”
   • [claimed-docs] “Being a vector database, Orama allows you to perform vector search natively.”

   proof ↗⚑ flag

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

   weight 3 · round drawn
   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

   Orama✓fullclaimed9/10

   Orama's docs explicitly describe hybrid search as combining full-text and vector search in one unique query, and this is corroborated in both the OSS library (GitHub feature list) and Orama Cloud docs. missing for 10: independent hands-on benchmark or third-party validation of fusion quality/performance.

   • [claimed-docs] “Hybrid search is an Orama feature that allows you to perform full-text and vector search in one unique query, combining the results to get t…”
   • [claimed-docs] “Full-text search - Vector search - Hybrid search - AI-powered NLP search”
   • [github] “Full-Text search... Vector Search... Hybrid Search... Search Filters... Geosearch... Pinning Rules (Merchandising)... Facets... Typo Toleran…”
   • [claimed-docs] “This plugin generates embeddings for your documents at insert and search time, allowing you to perform vector and hybrid searches on your do…”

   proof ↗⚑ flag

Rag

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

   weight 1 · round to Orama
   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

   Orama✓fullprobed8/10

   Orama documents an AnswerSession API for ChatGPT-like conversational answers with sources, built on vector/hybrid search and Secure Proxy to OpenAI, plus Orama Cloud's data-source/project model explicitly framed for RAG and retrieval, and a documented MCP server for AI interface integration. Missing for 10: no independent/hands-on corroboration of RAG output quality and no formal OpenAPI/answer-API reference spec (openapi probe 404s).

   • [claimed-docs] “allows you to perform ChatGPT-like experiences on your website”
   • [claimed-docs] “turns a question into a straight answer with the sources behind it”
   • [claimed-docs] “AnswerSession** that allows you to perform ChatGPT-like experiences on your website. It uses a free feature from Orama Cloud called **Secure…”
   • [claimed-docs] “AnswerSession** that allows you to perform ChatGPT-like experiences on your website.”
   • [claimed-docs] “we introduced a new feature called **AnswerSession** that allows you to perform ChatGPT-like experiences on your website.”
   • [claimed-docs] “A project is a set of **data sources** that you want to use for RAG, search, or any other method of retrieval.”
   • [claimed-docs] “A project is a set of data sources that you want to use for RAG, search, or any other method of retrieval.”
   • [claimed-docs] “you'll be able to interact with your data from different AI interfaces, including ChatGPT, Cursor, and many other”
   • [claimed-docs] “Every Orama Cloud project comes with an MCP server that is automatically configured to interact with your project's data.”
   • [probe] “official MCP server documented at https://docs.orama.com/docs/cloud/mcp-server”

   proof ↗⚑ flag

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

   weight 2 · round to Orama
   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

   Orama~partialclaimed5/10

   Orama documents `insertMultiple` explicitly for bulk-inserting large numbers of documents without blocking the event loop, which directly supports bulk operations for insertion. However, evidence does not show bulk update/delete operations or batch query/search operations across many items, so the story is only partially covered. Missing for 10: bulk update/delete APIs, batch search/query operations, and independent/hands-on verification of insertMultiple performance at scale.

   • [claimed-docs] “Inserting a large number of documents in a loop could potentially block the event loop. Instead `insertMultiple` handles this case better.”
   • [claimed-docs] “If you have a lot of records, we suggest using the `insertMultiple` function”
   • [claimed-docs] “Instead insertMultiple handles this case better.”

   proof ↗⚑ flag

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

   weight 3 · round drawn
   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

   Orama—none0/10

   Orama's evidence covers search, vector/hybrid search, facets, and an MCP server for AI interfaces, but nothing describes a rules/automation engine that triggers actions on events. The closest feature, 'Pinning Rules (Merchandising),' only affects search result ranking for specific queries, not general event-triggered automation. Missing for 10: any documentation of event listeners, triggers, webhooks, or conditional automation logic tied to data or search events.

   • [github] “Pinning Rules (Merchandising)”
   • [github] “Full-Text search... Vector Search... Hybrid Search... Search Filters... Geosearch... Pinning Rules (Merchandising)... Facets... Typo Toleran…”

   proof ↗⚑ flag

3. ai-native userSchedule recurring jobs or workflows

   weight 2 · round drawn
   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

   Orama—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

Onboarding

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

   weight 3 · round drawn
   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

   Orama~partialclaimed6/10

   Docs cover creating an instance with a schema, inserting documents (including insertMultiple for bulk), and running searches with filters/facets, which together map to a quickstart flow, but there is no single consolidated 'quickstart' walkthrough or independent hands-on confirmation of the end-to-end time-to-first-search experience. missing for 10: a dedicated quickstart guide/tutorial artifact, and independent/hands-on evidence confirming ease/time-to-first-search.

   • [claimed-docs] “We can create a new instance (from now on database) with an **indexing `schema`**.”
   • [claimed-docs] “Orama supports the following types: | Type | Description | Example | | ---------------- | ------------------------------------------------ |…”
   • [claimed-docs] “The schema represents the searchable properties of the document to be inserted.”
   • [claimed-docs] “insertion in Orama is quick and intuitive”
   • [claimed-docs] “Inserting a large number of documents in a loop could potentially block the event loop. Instead `insertMultiple` handles this case better.”
   • [claimed-docs] “If you have a lot of records, we suggest using the `insertMultiple` function”
   • [claimed-docs] “users can filter their search results by various criteria, such as category, price range, or other attributes”
   • [claimed-docs] “Facets are a powerful tool for filtering and narrowing down search results on the Orama search engine.”

   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
   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

   Orama~partialclaimed4/10

   Orama Cloud officially supports only JavaScript/TypeScript, Python, and Rust SDKs; there is no evidence of official PHP, Ruby, or Go SDKs, nor of active maintenance/currency across all these languages. Missing for 10: PHP, Ruby, Go SDK evidence, and documentation of update cadence/parity across all listed languages.

   • [claimed-docs] “Orama Cloud officially supports the following SDKs: - JavaScript/TypeScript - Python - Rust”

   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 drawn
   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

   Orama—none0/10

   The evidence pack covers Orama's search engine capabilities (facets, filters, vector/hybrid search, schema, insertion) and cloud/MCP integration, but contains no mention of any official prebuilt UI components (search box, results list, facet widgets, pagination) that a developer could assemble into a search interface. Missing for 10: any citation of a UI component library, widget, or pagination component from Orama.

   ⚑ flag

Connectors

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

   weight 1 · round to Orama
   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

   Orama~partialclaimed3/10

   Orama Cloud documentation describes a 'data source' abstraction for ingesting sets of documents (implying some built-in ingestion mechanism beyond manual SDK calls), but the evidence pack never names an official crawler, sitemap importer, or specific third-party connectors (e.g., web crawler, CMS, Elasticsearch, etc.). The open-source library's actual indexing API (insert/insertMultiple) is manual, not connector-based. Missing for 10: explicit documentation of a website crawler or named connector integrations, hands-on/independent confirmation of connector usage.

   • [claimed-docs] “A data source identifies a specific set of documents, ideally coming from a single origin.”
   • [claimed-docs] “you can put data that will be updated frequently in a single data source (let's call it `docs`), and put data that follows a different updat…”
   • [claimed-docs] “A project is a set of **data sources** that you want to use for RAG, search, or any other method of retrieval.”
   • [claimed-docs] “A project is a set of data sources that you want to use for RAG, search, or any other method of retrieval.”
   • [claimed-docs] “Inserting a large number of documents in a loop could potentially block the event loop. Instead `insertMultiple` handles this case better.”
   • [claimed-docs] “If you have a lot of records, we suggest using the `insertMultiple` function”

   proof ↗⚑ flag

Ingestion

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

   weight 2 · round to Orama
   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

   Orama~partialclaimed3/10

   Orama's docs confirm a bulk-insert API (`insertMultiple`) recommended for large record counts, addressing the 'bulk import' half of the story, but there is no evidence of any async task/job tracking mechanism, status polling, or completion notification for indexing jobs, nor any documented performance/scale claims for millions of documents. missing for 10: async task/job ID tracking, indexing-completion signals, and millions-scale benchmarks or documentation.

   • [claimed-docs] “Inserting a large number of documents in a loop could potentially block the event loop. Instead `insertMultiple` handles this case better.”
   • [claimed-docs] “If you have a lot of records, we suggest using the `insertMultiple` function”
   • [claimed-docs] “Instead insertMultiple handles this case better.”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   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

   Orama~partialclaimed5/10

   Orama documents insert/insertMultiple for adding documents and mentions data sources that can be updated frequently, implying documents become searchable quickly since it's an in-memory/JS index, but there is no explicit documentation of update/delete APIs, real-time reindex latency, or confirmation that deletes are reflected without a full reindex. missing for 10: explicit update/delete document API docs, evidence of near-real-time index refresh after writes, and any performance/latency data or independent confirmation of incremental indexing without full reindex.

   • [claimed-docs] “insertion in Orama is quick and intuitive”
   • [claimed-docs] “Inserting a large number of documents in a loop could potentially block the event loop. Instead `insertMultiple` handles this case better.”
   • [claimed-docs] “If you have a lot of records, we suggest using the `insertMultiple` function”
   • [claimed-docs] “you can put data that will be updated frequently in a single data source (let's call it `docs`), and put data that follows a different updat…”
   • [claimed-docs] “A data source identifies a specific set of documents, ideally coming from a single origin.”

   proof ↗⚑ flag

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

   weight 2 · round to Orama
   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

   Orama~partialprobed5/10

   Orama's core search/insert/facet/vector/hybrid features are all exposed via JS SDK APIs and Orama Cloud APIs, and Cloud also ships an MCP server for AI interfaces, suggesting broad API parity with UI features. However, there is no discoverable OpenAPI spec (probe found 404s across candidate paths), and no evidence explicitly confirming that every UI-configurable capability (e.g., Cloud dashboard settings, on-premise deployment configuration, answer-engine/AnswerSession setup) has a fully documented API equivalent. missing for 10: a published OpenAPI/API reference proving full UI-API parity, explicit confirmation that all dashboard/UI-only settings are API-configurable, and independent/hands-on verification of API completeness.

   • [claimed-docs] “you'll be able to interact with your data from different AI interfaces, including ChatGPT, Cursor, and many other”
   • [claimed-docs] “The APIs are designed to be as close as possible to the **Orama Cloud** APIs, so you can easily migrate your projects from **Orama Cloud** t…”
   • [claimed-docs] “Every Orama Cloud project comes with an MCP server that is automatically configured to interact with your project's data.”
   • [claimed-docs] “Orama Cloud officially supports the following SDKs: - JavaScript/TypeScript - Python - Rust”
   • [claimed-docs] “so you can easily migrate your projects from **Orama Cloud** to **Orama Open Source** and vice-versa”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.orama.com/openapi.json, https://docs.orama.com/swagger.json, https://docs.orama.com/api…”
   • [probe] “official MCP server documented at https://docs.orama.com/docs/cloud/mcp-server”

   proof ↗⚑ flag

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

   weight 3 · round drawn
   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

   Orama—none0/10

   The evidence pack never documents an explicit data-export or persistence feature (no mention of exporting indexes/documents to JSON, CSV, or any open format); only vague notes about migrating between Orama Cloud and Orama OSS APIs (orama-docs-19/29) exist, which is not the same as user-initiated data export. Since Orama is a data-handling search/AI platform, this axis is fair to ask, but no evidence shows the capability being delivered.

   • [claimed-docs] “The APIs are designed to be as close as possible to the **Orama Cloud** APIs, so you can easily migrate your projects from **Orama Cloud** t…”
   • [claimed-docs] “so you can easily migrate your projects from **Orama Cloud** to **Orama Open Source** and vice-versa”

   proof ↗⚑ flag

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

   weight 2 · round to Orama
   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

   Orama✓fullclaimed7/10

   Orama explicitly markets itself as 'the open-source search library' and maintains a public GitHub repository (oramasearch/orama) showcasing its full feature set, confirming the core engine's source is publicly available for inspection. Missing for 10: explicit citation of the specific open-source license (e.g., Apache-2.0/MIT) and independent third-party confirmation of license terms.

   • [claimed-docs] “The open-source search library. Add fast, relevant search to your own application at no cost.”
   • [github] “Stemming and tokenization in 30 languages”
   • [github] “Full-Text search... Vector Search... Hybrid Search... Search Filters... Geosearch... Pinning Rules (Merchandising)... Facets... Typo Toleran…”

   proof ↗⚑ flag

4. ai-native userSelf-host the core product

   weight 3 · round to Elasticsearch
   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

   Orama✓fullclaimed7/10

   Orama's core search library is explicitly open-source and free to self-host (orama-docs-12), and even the Cloud/RAG offering provides on-premise deployment of the context server on your own infrastructure (orama-docs-8), directly satisfying the self-hosting story for an AI-native user. Missing for 10: detailed self-hosting/deployment documentation (Docker/K8s instructions) and independent hands-on confirmation of a successful self-hosted setup.

   • [claimed-docs] “The open-source search library. Add fast, relevant search to your own application at no cost.”
   • [claimed-docs] “We offer on-premise support for Orama Cloud, allowing you to deploy the context server on your own infrastructure.”
   • [claimed-docs] “The APIs are designed to be as close as possible to the **Orama Cloud** APIs, so you can easily migrate your projects from **Orama Cloud** t…”

   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
   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

   Orama—none0/10

   Evidence covers search features (full-text, vector, hybrid, facets, MCP server) but no mention of built-in analytics dashboards for top queries, no-result queries, or click-through tracking. missing for 10: analytics dashboard docs, no-result query tracking, click-through rate reporting, any founder-facing insights UI.

   ⚑ 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
   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

   Orama—none0/10

   No evidence pack items describe clustering, replication, or high-availability architecture, nor any documented path from prototype-scale to hundreds of millions of documents; Orama Cloud is described only as 'managed at scale' and offers on-premise deployment, but no operational scaling/HA/clustering documentation is present.

   • [claimed-docs] “We offer on-premise support for Orama Cloud, allowing you to deploy the context server on your own infrastructure.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.orama.com/llms.txt # Docs ## cloud - [Introduction to Orama Cloud](/docs/cloud): Run Orama at sca…”

   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 Orama
   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

   Orama~partialclaimed6/10

   Orama ships a free open-source library that can be self-hosted (orama-docs-12) and also explicitly offers on-premise deployment of the 'context server' for Orama Cloud (orama-docs-8), and notes its OSS APIs are designed to closely mirror Cloud APIs for easy migration (orama-docs-19/29). However, the docs never claim full feature parity — the OSS/self-host path and the on-prem 'context server' appear to be distinct offerings, and Cloud-specific capabilities (hosted MCP server, managed SDpossible, Secure Proxy for AnswerSession, project/data-source management) are not shown as available in the self-hosted engine. Missing for 10: explicit statement/documentation that all hosted-product features (MCP server, Secure Proxy, managed data-source pipeline, SDKs) are available in the self-hosted deployment, and independent/hands-on confirmation of feature parity.

   • [claimed-docs] “We offer on-premise support for Orama Cloud, allowing you to deploy the context server on your own infrastructure.”
   • [claimed-docs] “The open-source search library. Add fast, relevant search to your own application at no cost.”
   • [claimed-docs] “The APIs are designed to be as close as possible to the **Orama Cloud** APIs, so you can easily migrate your projects from **Orama Cloud** t…”
   • [claimed-docs] “so you can easily migrate your projects from **Orama Cloud** to **Orama Open Source** and vice-versa”

   proof ↗⚑ flag

Pricing

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

   weight 2 · round to Elasticsearch
   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

   Orama—none0/10

   The evidence pack contains no pricing tiers, usage-based cost details, or discussion of per-request billing/predictability beyond the fact that the open-source library is free; there is no documentation of Orama Cloud's paid pricing structure or how costs scale with records/query volume. missing for 10: Orama Cloud pricing tiers, usage-based billing details, any statement about cost predictability at scale.

   • [claimed-docs] “The open-source search library. Add fast, relevant search to your own application at no cost.”

   proof ↗⚑ flag

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

   weight 3 · round drawn
   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

   Orama—none0/10

   The only pricing-related evidence is a single line noting the open-source library is free; there is no evidence of published per-unit pricing (e.g., cost per search, per record, or per node) for Orama Cloud that would let a founder predict costs before committing. Missing for 10: any documented pricing tiers, unit costs, or usage-based pricing calculator for Orama Cloud.

   • [claimed-docs] “The open-source search library. Add fast, relevant search to your own application at no cost.”

   proof ↗⚑ flag

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

   weight 2 · round to Orama
   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

   Orama~partialclaimed5/10

   Orama Cloud offers on-premise deployment, letting customers host the context server on their own infrastructure, and the open-source library can be self-hosted anywhere — both effectively let a user control data location. However there is no evidence of a formal multi-region selection feature (e.g., choosing EU/US Orama Cloud regions) or documented data-residency guarantees for the hosted Cloud offering. missing for 10: explicit region-selection UI/API for Orama Cloud, documented data residency/compliance certifications, independent confirmation of self-hosting meeting residency requirements.

   • [claimed-docs] “We offer on-premise support for Orama Cloud, allowing you to deploy the context server on your own infrastructure.”
   • [claimed-docs] “The open-source search library. Add fast, relevant search to your own application at no cost.”

   proof ↗⚑ flag

2. ai-native userControl data retention and deletion

   weight 2 · round drawn
   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

   Orama—none0/10

   No evidence in the pack addresses data retention policies, deletion controls, TTL/data lifecycle, or user-initiated deletion of indexed/embedded data; the docs cover search, indexing, and MCP features but say nothing about retention/deletion controls.

   ⚑ flag

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

   weight 2 · round drawn
   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

   Orama—none0/10

   No evidence in the pack addresses telemetry, usage tracking, or an opt-out mechanism for Orama's open-source library or Cloud offering; this is an applicable axis for any AI-native tool but the pack provides no documentation of a telemetry policy or opt-out flag.

   ⚑ flag

Curation

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

   weight 2 · round to Orama
   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

   Orama~partialclaimed5/10

   Orama's GitHub README explicitly lists 'Pinning Rules (Merchandising)' as a feature, directly supporting query-specific result pinning/curation, but no evidence pack item documents synonym definition or explicit boost/hide controls beyond the general 'merchandising' label. missing for 10: synonym dictionary/configuration docs, explicit boost and hide mechanisms, and any hands-on or independent confirmation of pinning behavior in practice.

   • [github] “Pinning Rules (Merchandising)”
   • [github] “Full-Text search... Vector Search... Hybrid Search... Search Filters... Geosearch... Pinning Rules (Merchandising)... Facets... Typo Toleran…”

   proof ↗⚑ flag

Ranking

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

   weight 2 · round to Orama
   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

   Orama~partialclaimed5/10

   Orama exposes 'Pinning Rules (Merchandising)' for boosting specific results and search filters/facets that can approximate business-signal filtering, but there is no documented support for custom ranking formulas incorporating popularity, recency, or margin as scoring signals beyond textual relevance. missing for 10: documented custom scoring/boost-by-field (e.g. recency decay, popularity weighting, margin-based ranking), configurable ranking function API, and evidence of combining multiple business signals into the relevance score.

   • [github] “Full-Text search... Vector Search... Hybrid Search... Search Filters... Geosearch... Pinning Rules (Merchandising)... Facets... Typo Toleran…”
   • [github] “Pinning Rules (Merchandising)”
   • [claimed-docs] “users can filter their search results by various criteria, such as category, price range, or other attributes”
   • [claimed-docs] “Facets are a powerful tool for filtering and narrowing down search results on the Orama search engine.”

   proof ↗⚑ flag

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

   weight 1 · round drawn
   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

   Orama—none0/10

   No evidence of score/relevance explanation, ranking debug tools, or explain-style APIs; documentation covers search features (facets, hybrid, vector) and algorithm selection but nothing about inspecting or explaining why a document ranked where it did. Missing for 10: score breakdown/explain API, ranking debug docs, any transparency into scoring internals.

   • [claimed-docs] “Orama Cloud gives you the flexibility to choose the search algorithm that best suits your needs.”
   • [claimed-docs] “Full-text search - Vector search - Hybrid search - AI-powered NLP search”

   proof ↗⚑ flag

Experience

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

   weight 2 · round drawn
   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

   Orama—none0/10

   The evidence pack covers full-text/vector/hybrid search, facets, filters, and an AI answer engine, but nowhere mentions autocomplete, typeahead, or query-suggestion features driven by search traffic or a dedicated suggestions index.

   ⚑ flag

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

   weight 3 · round to Orama
   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

   Orama~partialclaimed5/10

   Orama is documented as a fast, in-memory full-text search engine ('fast, relevant search', 'insertion is quick and intuitive') suitable for real-time query use cases, but the evidence never explicitly describes an as-you-type UI pattern or cites millisecond-level latency benchmarks. missing for 10: explicit as-you-type/keystroke-search documentation, published latency/benchmark numbers, hands-on confirmation of instant search UX.

   • [claimed-docs] “The open-source search library. Add fast, relevant search to your own application at no cost.”
   • [claimed-docs] “insertion in Orama is quick and intuitive”
   • [github] “Full-Text search... Vector Search... Hybrid Search... Search Filters... Geosearch... Pinning Rules (Merchandising)... Facets... Typo Toleran…”

   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 Orama
   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

   Orama~partialclaimed4/10

   GitHub feature list explicitly confirms Orama ships 'Typo Tolerance' out of the box, but no evidence details how it can be tuned (e.g., threshold, per-field settings, exact-match toggles). missing for 10: documentation on configurable tolerance levels, per-field fuzzy rules, and independent confirmation of tuning behavior.

   • [github] “Full-Text search... Vector Search... Hybrid Search... Search Filters... Geosearch... Pinning Rules (Merchandising)... Facets... Typo Toleran…”
   • [github] “Typo Tolerance”

   proof ↗⚑ flag

Filtering

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

   weight 2 · round to Orama
   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

   Orama✓fullclaimed8/10

   Orama's docs explicitly describe a dedicated Faceted Search API that generates facets at search-time based on schema, supporting filtering by category, price range, and other attributes in a single query (orama-docs-3, orama-docs-17, orama-docs-27, orama-docs-34), and this is listed as a core engine feature alongside filters/facets in the GitHub feature list (orama-gh-2). Missing for 10: explicit documentation/example showing live counts per facet value returned in the same response, and independent/hands-on corroboration beyond first-party docs.

   • [claimed-docs] “users can filter their search results by various criteria, such as category, price range, or other attributes”
   • [claimed-docs] “Orama will be able to generate facets at search-time based on the schema.”
   • [claimed-docs] “Facets are a powerful tool for filtering and narrowing down search results on the Orama search engine.”
   • [claimed-docs] “the Orama Faceted Search API is the perfect solution for adding faceted search functionality to your project”
   • [github] “Full-Text search... Vector Search... Hybrid Search... Search Filters... Geosearch... Pinning Rules (Merchandising)... Facets... Typo Toleran…”

   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
   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

   Orama—none0/10

   No evidence describes scoped/tenant-specific API keys or per-user document restriction; documentation covers filters, facets, and data sources but nothing about restricting an individual end user's search to only their own documents without separate indexes. Missing for 10: any mention of tenant/user-scoped tokens, per-user document access control, or multitenancy security guarantees.

   ⚑ flag