Databases Azure Cosmos DB premium

Full-text search in Cosmos DB

Full-text search in Cosmos DB is the Azure Cosmos DB for NoSQL capability that lets selected text fields be indexed and queried by meaningfully matching words instead of only exact values. Teams use it to build search features inside a Cosmos DB application when text relevance, hybrid retrieval, or document search must stay close to transactional data. In daily Azure work, it shows up when engineers design product search, rank support articles, combine text and vector retrieval, tune index policy, or investigate why a query misses expected documents.

Aliases
Cosmos DB full-text search, full text search for NoSQL, Cosmos DB text search
Difficulty
advanced
CLI mappings
4
Last verified
2026-05-14

Microsoft Learn

An Azure Cosmos DB for NoSQL capability that indexes configured text paths and enables full-text query and scoring functions over JSON document content.

Microsoft Learn: Use full-text search in Azure Cosmos DB2026-05-14

Technical context

Technically, Full-text search in Cosmos DB is configured through a Cosmos DB for NoSQL account, database, container, full-text policy, full-text index entries in the indexing policy, text paths, language settings, query functions, and SDK queries. Important settings include full-text paths, default language, per-path language, indexing policy, partition key, throughput model, consistency level, query shape, SDK version, and feature enablement for the account. Operators inspect it with container policy JSON, indexing policy output, query metrics, request units, SDK logs, portal Data Explorer results, Azure Monitor metrics, and deployment templates for container updates.

Why it matters

Full-text search in Cosmos DB matters because it turns architecture intent into runtime behavior. When teams misunderstand it, they may change the wrong scope, grant access too broadly, overload capacity, hide a data exposure path, or chase an application bug that is really platform configuration. For this term, that means search behavior depends on explicit text paths and indexing policy, so teams must know what is searchable before promising relevance, cost, or latency targets. It affects security, reliability, operations, cost, and performance because one choice can change how users, identities, traffic, data, deployments, or events behave. Review owner, scope, evidence, dependencies, and rollback before production change.

Where you see it

Signals, screens, and Azure surfaces where this term usually becomes operational.

Signal 01

A container definition includes a full-text policy that declares text paths and language, plus indexing-policy entries that enable full-text operations on those paths. Review owner, scope, evidence, dependencies, and rollback before production change.

Signal 02

Queries use Cosmos DB for NoSQL full-text functions and return request-unit charges, query metrics, relevance scores, continuation tokens, and matched document properties. Review owner, scope, evidence, dependencies, and rollback before production change.

Signal 03

Architecture notes mention hybrid search, combining full-text scoring with vector search or semantic reranking while keeping source data in one Cosmos DB container. Review owner, scope, evidence, dependencies, and rollback before production change.

When this becomes relevant

Specific situations where this term helps solve real Azure design, operations, migration, security, reliability, cost, or governance problems.

  • Design and document Full-text search in Cosmos DB before a production release changes traffic, identity, data access, deployment, or runtime behavior.
  • Use Full-text search in Cosmos DB during incident triage to narrow the affected scope and gather evidence before changing live settings.
  • Review Full-text search in Cosmos DB during architecture, security, cost, performance, and reliability planning for the workload.

Real-world case studies

Different enterprise-style examples that show the term being used to hit measurable objectives.

Case study 01

Full-text search in Cosmos DB in action for retail product discovery

Scenario, objectives, solution, measured impact, and takeaway.

Scenario

WideWorld Outfitters, an online retailer, needed faster product search over descriptions stored in Azure Cosmos DB for NoSQL without duplicating every document into a separate search system.

Business/Technical Objectives
  • Search product descriptions by text relevance
  • Keep transactional data in Cosmos DB
  • Control request-unit consumption
  • Support future hybrid search
Solution Using Full-text search in Cosmos DB

The data team used Full-text search in Cosmos DB by updating the container with a full-text policy for product title and description paths and adding full-text index entries to the indexing policy. Engineers tested queries with text functions, reviewed request-unit charges, and kept the existing partition key for catalog categories. Application code returned scored matches and could later combine text scoring with vector search for recommendations. Operators saved container policy JSON and throughput evidence before production rollout. Architects documented ownership, rollback steps, monitoring signals, and approval evidence so support staff could operate the design without guessing during incidents. The rollout included a lower-environment test, a named business owner, and a short runbook explaining what to verify before and after release.

Results & Business Impact
  • Search latency stayed below 180 milliseconds for common queries
  • Separate search infrastructure was avoided
  • RU budget alerts caught expensive test queries
  • Hybrid search design was approved for phase two
Key Takeaway for Glossary Readers

Full-text search in Cosmos DB is valuable when teams need relevance queries close to operational NoSQL data.

Case study 02

Full-text search in Cosmos DB in action for healthcare knowledge retrieval

Scenario, objectives, solution, measured impact, and takeaway.

Scenario

CareBridge Clinics, a healthcare network, stored internal policy documents as JSON records and needed clinicians to find relevant guidance quickly.

Business/Technical Objectives
  • Search approved policy text
  • Avoid indexing sensitive free-form notes
  • Keep audit evidence for searchable paths
  • Meet query latency targets
Solution Using Full-text search in Cosmos DB

The team used Full-text search in Cosmos DB on a controlled policy container, not on patient note containers. Architects declared only approved policy text paths in the full-text policy, added the matching full-text index, and documented the language setting. Queries were tested through the SDK with request-unit metrics and security review. Private endpoint access, role assignments, and diagnostic logs were checked before release. The application showed search results with document type filters so clinicians did not confuse policies with patient records. Architects documented ownership, rollback steps, monitoring signals, and approval evidence so support staff could operate the design without guessing during incidents. The rollout included a lower-environment test, a named business owner, and a short runbook explaining what to verify before and after release. Security, reliability, cost, and performance evidence were captured together so reviewers could see the operational tradeoffs rather than only the deployment result.

Results & Business Impact
  • Searchable paths matched the data classification review
  • Average policy lookup time fell by 55 percent
  • No patient-note paths were indexed
  • Audit reviewers accepted the policy evidence
Key Takeaway for Glossary Readers

Text search becomes safer when teams explicitly choose which Cosmos DB paths are searchable and why.

Case study 03

Full-text search in Cosmos DB in action for legal case workspace

Scenario, objectives, solution, measured impact, and takeaway.

Scenario

Litware Legal Services, a legal technology firm, needed keyword and relevance search over case summaries while keeping document metadata in Cosmos DB.

Business/Technical Objectives
  • Rank case summaries by text relevance
  • Track request-unit cost per workspace
  • Support vector search later
  • Keep permissions at tenant workspace scope
Solution Using Full-text search in Cosmos DB

The engineering team used Full-text search in Cosmos DB for summary and tag fields inside each workspace container. They added a full-text policy, tuned the indexing policy, and reviewed queries with continuation tokens under realistic workspace sizes. The application enforced tenant authorization before queries ran, and diagnostics captured RU charges by operation. Designers documented how full-text search differed from Azure AI Search so stakeholders understood the current scope and future integration path. Architects documented ownership, rollback steps, monitoring signals, and approval evidence so support staff could operate the design without guessing during incidents. The rollout included a lower-environment test, a named business owner, and a short runbook explaining what to verify before and after release. Security, reliability, cost, and performance evidence were captured together so reviewers could see the operational tradeoffs rather than only the deployment result.

Results & Business Impact
  • Relevant summaries appeared in the first result page
  • RU usage stayed within the approved budget
  • Tenant access controls were preserved
  • Future vector-search paths were documented
Key Takeaway for Glossary Readers

Full-text search gives Cosmos DB workloads a practical relevance layer when index policy, cost, and security are handled deliberately.

Why use Azure CLI for this?

CLI checks make Full-text search in Cosmos DB review repeatable because they capture scoped evidence for configuration, ownership, dependencies, health, and change impact before operators modify production.

CLI use cases

  • List or show the Azure resources related to Full-text search in Cosmos DB before selecting a target for deeper review.
  • Capture read-only evidence for Full-text search in Cosmos DB during release approval, incident response, access review, or cost investigation.
  • Compare configuration, metrics, logs, and dependent resources for Full-text search in Cosmos DB across environments before approving a mutating command.

Before you run CLI

  • Confirm tenant, subscription, resource group, application, profile, account, endpoint, or deployment scope before trusting command output.
  • Run list and show commands first, then save evidence before create, update, restart, delete, purge, scale, or access changes.
  • Check whether the command affects customer traffic, credentials, cached content, model behavior, data access, cost, or compliance evidence.

What output tells you

  • Names, resource IDs, locations, SKUs, enabled states, and parent relationships show whether you are inspecting the intended target.
  • Settings, identities, routes, deployments, indexes, endpoints, origins, or app settings explain how requests and workloads behave today.
  • Timestamps, metrics, usage, health state, and logs help separate Azure configuration issues from application or downstream failures.

Mapped Azure CLI commands

Full-text search in Cosmos DB operational checks

direct
az cosmosdb sql container show --account-name <account> --database-name <database> --name <container> --resource-group <resource-group>
az cosmosdb sql containerdiscoverDatabases
az cosmosdb sql container create --account-name <account> --database-name <database> --name <container> --partition-key-path <path> --idx @index-policy.json --resource-group <resource-group>
az cosmosdb sql containerprovisionDatabases
az cosmosdb sql container throughput show --account-name <account> --database-name <database> --name <container> --resource-group <resource-group>
az cosmosdb sql container throughputdiscoverDatabases
az cosmosdb show --name <account> --resource-group <resource-group>
az cosmosdbdiscoverDatabases

Architecture context

Technically, Full-text search in Cosmos DB is configured through a Cosmos DB for NoSQL account, database, container, full-text policy, full-text index entries in the indexing policy, text paths, language settings, query functions, and SDK queries. Important settings include full-text paths, default language, per-path language, indexing policy, partition key, throughput model, consistency level, query shape, SDK version, and feature enablement for the account. Operators inspect it with container policy JSON, indexing policy output, query metrics, request units, SDK logs, portal Data Explorer results, Azure Monitor metrics, and deployment templates for container updates.

Security

Security for Full-text search in Cosmos DB starts with queryable text paths, sensitive fields, account keys or Entra permissions, private endpoints, diagnostic logs, SDK access, data classification, and whether search exposes regulated content. Review who can create, update, delete, execute, read logs, approve dependencies, and manage credentials or identities. Prefer Microsoft Entra ID, managed identity, private networking, least privilege, and audited automation where the service supports them. Keep secrets out of code and avoid broad public exposure unless there is a documented exception. Capture role assignments, diagnostic settings, policy decisions, Activity Log entries, and owner approvals so access and data handling are intentional and reviewable.

Cost

Cost for Full-text search in Cosmos DB is driven by request units for text queries, indexing overhead, data size, cross-partition queries, diagnostics, provisioned throughput, serverless usage, failed experiments, and duplicate external search systems. The expensive mistake is not only Azure consumption; it can also be duplicate experiments, emergency support, overprovisioned capacity, unnecessary data transfer, or cleanup after weak design evidence. Review whether the workload truly needs the selected tier, retention, diagnostics, network path, scale rule, cache behavior, or automation pattern. Use tags, budgets, alerts, and cleanup reviews so teams can explain why the design exists and remove stale resources safely.

Reliability

Reliability for Full-text search in Cosmos DB depends on index policy correctness, feature enablement, partition design, RU availability, SDK behavior, consistency expectations, query fallback, regional failover, and how policy changes affect production traffic. A resource can be present and still fail the business workflow if routing, identity, quota, storage, code, cache, scale, or downstream health is wrong. Test failure modes, retries, deployment behavior, disabled states, rollback steps, and maintenance windows before relying on the design. During incidents, compare platform metrics, logs, deployment history, and application traces from the same time window before changing production. The goal is a recoverable configuration support teams can verify quickly.

Performance

Performance for Full-text search in Cosmos DB depends on index selectivity, partition key design, query functions, text path count, RU budget, result size, continuation tokens, SDK options, regional latency, and whether hybrid search also uses vectors. Measure platform metrics and application-side completion times because a fast control-plane response does not prove users received the right result. Test with realistic regions, data sizes, concurrency, authentication paths, route choices, cache state, package size, and downstream limits. When performance regresses, compare configuration changes, resource limits, client logs, diagnostic data, and workload timing before adding capacity or blaming one service. Tune with evidence from the exact environment and traffic pattern.

Operations

Operations for Full-text search in Cosmos DB require policy review, query testing, RU monitoring, feature registration evidence, SDK version tracking, deployment approvals, search relevance checks, and rollback of container indexing changes. Before a change, capture read-only CLI output, portal evidence when useful, owner tags, expected behavior, and rollback steps. During incidents, avoid changing several settings at once; compare metrics, logs, deployment operations, identity evidence, network state, and downstream health first. Keep runbooks clear enough for support teams to verify current behavior quickly. Good operations make the term observable, reviewable, and recoverable during releases, audits, and incidents. Review owner, scope, evidence, dependencies, and rollback before production change.

Common mistakes

  • Treating Full-text search in Cosmos DB as a simple label instead of checking the live scope, owner, dependencies, and current configuration.
  • Running a mutating command for Full-text search in Cosmos DB in the wrong subscription, resource group, app, profile, route, or account context.
  • Assuming successful deployment proves Full-text search in Cosmos DB works without checking logs, metrics, user behavior, and rollback evidence.