Azure Cosmos DB’s full-text search capabilities can improve price performance and simplify application architecture by consolidating operational data and search in a single service. For customers currently using Elasticsearch, these capabilities create a practical path to bringing operational data and search together in Azure Cosmos DB, particularly when the application’s data already lives there.This guide is for teams evaluating migration from Elasticsearch to Azure Cosmos DB. It explains how the two architectures differ, maps common Elasticsearch search capabilities to their Azure Cosmos DB equivalents, and identifies the design considerations and tradeoffs to assess before migrating a search workload. The central difference is where search lives in the application stack: Elasticsearch typically operates as a separate search cluster, while Azure Cosmos DB provides search directly over the operational data stored in the database.Architecture A separate search cluster adds a data movement path between the operational database and the search index. Data must be copied, indexed, and kept synchronized so search results reflect the latest application state. Azure Cosmos DB uses a different model: the database and full-text search capabilities are part of the same service. This can simplify the architecture, but it also means search should be designed as part of the database workload, with attention to partitioning, indexing, query shape, result size, and request-unit usage. Search FeaturesFeature Supported? Details Multilingual full-text search ✅ Yes Multi-language support is in preview. A full list of currently supported languages is available here. Phrase search ✅ Yes Use FullTextContains for exact phrases; use FullTextContainsAll/ Any for term-based matching. Learn more here. Stopword removal ✅ Yes Built into full-text indexing with tokenization and stemming. Currently only available in English. Custom stopword removal is currently in development. A full list of supported stopwords is available here. Full-text ranking (BM25) ✅ Yes FullTextScore returns BM25 relevance scores for ranking and can be used in ORDER BY RANK and RRF. Scores cannot currently be projected in query results. Score projection and score explanation capabilities are under development. Learn more here. Fuzzy search ✅ Preview Maximum edit distance 2 and up to 10 suggestions. Learn more here. Term boosting / weighted relevance ✅ Yes, via weights. No dedicated term-boosting operator. Use weighted Reciprocal Rank Fusion (RRF) across FullTextScore and/or VectorDistance. Learn more here. Weighted BM25 is currently in development. Hybrid search ✅ Yes Combines full-text BM25 scoring and vector search using RRF. Requires both full-text and vector policies/indexes. Learn more here. Faceting ✅ Yes, via aggregates No dedicated facet operator. Implement facet counts with aggregate queries such as GROUP BY, COUNT, and COUNTIF over the same search criteria. Learn more here. Pagination ✅ Yes Use continuation tokens for scalable paging. OFFSET LIMIT works but is better for small skips than for deep pagination. Learn more here. Hit highlighting ⚠️ Coming Soon Native hit highlighting is currently in development. Score explanation / score projection ⚠️ Coming Soon Support for exposing ranking scores, score components, weighting factors, and relevance explanations to applications is currently in development. Autocomplete / typeahead ⚠️ App-side No native autocomplete/typeahead API documented. Use app logic, or prefix fields if this is core. Performance and Cost For many workloads, Azure Cosmos DB can lower total cost and improve performance by replacing a separate Elasticsearch search tier with a single managed service for both operational data and search. This reduces infrastructure, operational, and synchronization overhead. Actual cost, latency, and throughput depend on workload characteristics such as indexing, query patterns, data distribution, availability requirements, and regional replication Key Takeaway Azure Cosmos DB is not a separate search tier; it is an operational database with built-in full-text, vector, and hybrid search capabilities. For customers migrating from Elasticsearch, this integrated approach can simplify the application architecture by bringing operational data and search together in one managed service. However, the two systems are not identical, and some specialized Elasticsearch capabilities, such as synonym management, proximity search, advanced autocomplete, and built-in hit highlighting, are not currently available natively in Azure Cosmos DB or require application-side implementation. However, Azure Cosmos DB search is evolving rapidly, with new functionality and capabilities being added regularly. Customers should evaluate the features available today while also considering the platform’s continued investment and expanding search capabilities when planning a migration. Series roadmap This post is the first in a series on migrating Elasticsearch-backed search workloads to Azure Cosmos DB. In the next posts, we’ll move from overview to implementation: Blog 2 will cover migrating Elasticsearch mappings to Azure Cosmos DB, including index definitions, analyzers, and field configuration. Blog 3 will then walk through query translation, showing how an Elasticsearch Search Request can be translated into an Azure Cosmos DB query pattern.