Cosmos DB full text index - Azure Glossary

Understand the concept

In plain English

Cosmos DB full-text index means a specialized index path for Azure Cosmos DB for NoSQL that enables text search and relevance scoring over selected string fields. In Cosmos DB, it appears when teams need lexical search, ranked results, hybrid search patterns, or retrieval over product descriptions, documents, support articles, or messages. It controls full-text policy paths, fullTextIndexes in the indexing policy, tokenization, stemming, stop words, BM25 scoring, query functions, and RU impact. Teams should know owner, affected data, limits, and verification path before production changes. That shared language keeps developers, operators, security reviewers, and finance teams aligned.

Why it matters

Cosmos DB full-text index matters because text-heavy applications need relevant search without forcing every keyword workload into a separate search system. It turns an abstract database concept into something teams can operate, secure, recover, and explain. If misunderstood, teams can face missing indexed paths, high RU queries, poor relevance, stale expectations about tokenization, ungoverned sensitive text search, and production writes slowed by index changes. For glossary readers, it shows where the term sits in the Cosmos DB model, which settings are safe to inspect, which changes require review, and which metrics, logs, or ownership records responders should check first. It keeps design reviews evidence-based.

Technical context

Technically, Cosmos DB full-text index uses NoSQL indexing policy configuration that declares full-text paths and supports full-text search functions and scoring in queries. Configure it through container full-text policy, indexing policy updates, NoSQL queries, SDK deployment scripts, feature enablement, and optional hybrid search designs. Verify with container indexing policy output, query results, relevance scores, RU charges, diagnostics, indexed paths, and application search tests. Key choices include text paths, language behavior, indexing policy, vector or hybrid search pairing, query filters, result limits, partition key, and rollout plan. Capture scope, region, identity, capacity, backup state, owner, and rollback trigger.

Exam context

Compare with

Azure AI Search Cosmos DB composite index Indexing policy Vector index

Where it is used

Where you see it

In the Azure portal, Cosmos DB full-text index appears near NoSQL container indexing policy, full-text policy configuration, Data Explorer queries; operators confirm scope, environment, readiness, and whether it belongs to production today.
In CLI, SDK, or IaC output, Cosmos DB full-text index appears through container show output, indexingPolicy fullTextIndexes, fullTextPolicy fields; those fields create repeatable review evidence for audits, incidents, handoffs, and pull requests.
In monitoring and support work, Cosmos DB full-text index appears beside search latency, RU charge, failed queries; those signals connect symptoms to security, reliability, cost, and performance.

Common situations

teams need lexical search, ranked results, hybrid search patterns, or retrieval over product descriptions, documents, support articles, or messages.
text-heavy applications need relevant search without forcing every keyword workload into a separate search system.
Use production evidence for Cosmos DB full-text index during architecture reviews, incidents, and support handoffs.
Connect Cosmos DB full-text index decisions to security, reliability, cost, operations, and performance outcomes.

Illustrative Azure scenarios

These examples show how the concept can affect design and operations. They are illustrative scenarios, not customer claims.

Scenario 01 Support article search Scenario, objectives, solution, measured impact, and takeaway.

Scenario

CloudDesk Software wanted better search inside support articles stored in Cosmos DB without moving every article to a separate system.

Goals

Return relevant articles in under 200 milliseconds
Improve first-click success for support agents
Limit searchable fields to approved knowledge content
Measure RU impact before full rollout

Approach using Cosmos DB full text index

Architects added a Cosmos DB full-text index for article title, summary, and approved body fields in the NoSQL container. The indexing policy was reviewed by security to exclude internal notes and customer identifiers. Search queries used full-text scoring and filters for product version and language. A pilot compared relevance, RU charge, and latency against the previous keyword filter. Application teams stored indexing policy changes in source control and used CLI to confirm container policy after deployment. Dashboards tracked search latency, failed queries, and agent first-click behavior. The team also added owner approval, validation evidence, and post-release monitoring for the support article search workflow. Support notes captured rollback triggers, dashboard links, and escalation contacts so responders could act without tribal knowledge.

Potential outcomes

Search P95 latency averaged 143 milliseconds
Agent first-click success improved by 21 percent
Sensitive internal notes were excluded from indexed paths
RU impact stayed within the approved search budget

What to learn

Full-text indexes help Cosmos DB search workloads when indexed fields, relevance tests, and RU baselines are reviewed together.

Scenario 02 Product discovery relevance Scenario, objectives, solution, measured impact, and takeaway.

Scenario

LumaHome Retail needed ranked product search over descriptions, materials, and care instructions stored in Cosmos DB for NoSQL.

Goals

Improve search relevance for common shopping terms
Keep product search under 250 milliseconds P95
Avoid indexing supplier-only notes
Support hybrid ranking experiments later

Approach using Cosmos DB full text index

The engineering team configured full-text policy paths for customer-facing product text and added fullTextIndexes in the container indexing policy. Product search queries combined text scoring with category and availability filters. Supplier-only notes and internal merchandising comments were excluded from searchable paths after a privacy and merchandising review. A controlled rollout measured RU, latency, relevance, and zero-result searches. The team kept vector and hybrid search experiments isolated until the baseline lexical search performed reliably. Operators documented rollback steps for the indexing policy and dashboards for search cost. The team also added owner approval, validation evidence, and post-release monitoring for the product discovery relevance workflow. Support notes captured rollback triggers, dashboard links, and escalation contacts so responders could act without tribal knowledge.

Potential outcomes

Common-query relevance improved by 18 percent in user testing
Search P95 latency reached 211 milliseconds
Excluded internal notes did not appear in search results
Zero-result searches dropped by 14 percent after tuning

What to learn

A Cosmos DB full-text index can improve product discovery when teams index only customer-appropriate fields and measure relevance like a product feature.

Scenario 03 Legal brief retrieval Scenario, objectives, solution, measured impact, and takeaway.

Scenario

Northstar Legal Services stored case notes and brief summaries in Cosmos DB and needed faster text retrieval for research assistants.

Goals

Search approved brief summaries by legal concept
Keep confidential client identifiers out of indexed paths
Rank results by relevance rather than simple substring matches
Provide audit evidence for indexed text fields

Approach using Cosmos DB full text index

Architects created a full-text index on approved summary and topic fields in the NoSQL container. Client identifiers, privileged notes, and billing comments remained outside the full-text policy. Research assistants searched through an internal portal that applied matter-level authorization before running queries. Full-text scoring ranked summaries, while filters limited results by practice area and jurisdiction. The deployment pipeline stored the indexing policy in source control, and CLI output verified the fullTextIndexes configuration after release. Monitoring tracked query RU, latency, failed searches, and access denials. The team also added owner approval, validation evidence, and post-release monitoring for the legal brief retrieval workflow. Support notes captured rollback triggers, dashboard links, and escalation contacts so responders could act without tribal knowledge.

Potential outcomes

Research search time dropped from 12 minutes to under three minutes
No confidential identifier fields were included in indexed paths
Result ranking reduced duplicate manual review by 29 percent
Audit evidence listed every searchable text path

What to learn

Full-text indexing is valuable for document retrieval only when searchability, relevance, and sensitive-field boundaries are designed together.

Azure CLI

Use CLI to capture indexing policy and throughput evidence before changing full-text paths or search query behavior.

Useful for

Inspect whether a container has full-text indexes configured.
Apply reviewed indexing policy changes through deployment automation.
Compare RU and latency before and after search rollout.

Before you run a command

Confirm the feature is enabled for the account and container scenario.
Review indexed text paths for sensitive data and write impact.
Test queries and rollback policy changes outside production first.

What the output tells you

Container output shows full-text policy and indexing policy paths.
Throughput output shows capacity available for search queries and writes.
Diagnostics show whether query cost or relevance changed after rollout.

Mapped commands

Cosmos DB full-text index CLI checks

direct

az cosmosdb sql container show --account-name <account> --resource-group <resource-group> --database-name <database> --name <container>

az cosmosdb sql containerdiscoverDatabases

az cosmosdb sql container update --account-name <account> --resource-group <resource-group> --database-name <database> --name <container> --idx @indexing-policy.json

az cosmosdb sql containerconfigureDatabases

az cosmosdb sql container throughput show --account-name <account> --resource-group <resource-group> --database-name <database> --name <container>

az cosmosdb sql container throughputdiscoverDatabases

Architecture context

A Cosmos DB full-text index is an indexing-policy decision for NoSQL containers that need text search inside the database instead of delegating every query to an external search service. I review it with the same seriousness as partitioning because it changes write cost, index storage, query eligibility, and relevance behavior. The architecture should identify which string paths are indexed, which language assumptions matter, how BM25 scoring is used, and whether full-text search is paired with vector or filtered queries. Teams also need rollout plans because index changes can affect RU consumption and query performance during deployment. Operators should compare indexed paths, query diagnostics, request charges, result ranking, and application relevance tests. The index is valuable when it targets real search fields, not every blob of text.

Security: Security for Cosmos DB full-text index starts with knowing which text fields are indexed, searchable, logged, exported, or returned to applications and whether they contain sensitive content. Review RBAC, data-plane permissions, keys, managed identities, firewall rules, private endpoints, encryption, diagnostics, and backup access. Avoid broad admin access just because a team needs to troubleshoot one resource or feature. Sensitive data can appear in query output, logs, support tickets, exports, or downstream processors. Operators should prefer read-only discovery, store secrets in approved locations, and document every emergency change. The safest design proves who can read data, who can change configuration, and how denied access is logged and reviewed.
Cost: Cost for Cosmos DB full-text index comes from index maintenance, write overhead, query RU, larger result sets, hybrid search experiments, storage growth, monitoring, and tuning time for relevance tests. Some spending is direct, while other costs appear as retries, duplicate processing, larger logs, extra environments, migration effort, or staff time during investigations. Review budgets, tags, expected usage, retention, alert thresholds, and change windows before scaling or enabling new behavior. Compare the cost of prevention, monitoring, and testing with the cost of an outage or data repair. The safest cost review ties spending to owner, workload value, measured demand, and rollback plan. Include both steady-state and incident-driven costs in the review.
Reliability: Reliability for Cosmos DB full-text index depends on indexing policy correctness, feature enablement, partition strategy, query tests, rollout timing, SDK behavior, and fallback search behavior during updates. Define the expected failure mode before production use, including what happens during regional incidents, throttling, expired credentials, schema drift, blocked network paths, or restore activity. Monitor health, latency, request units, errors, retry rate, backlog, and stale-data indicators rather than trusting a single success message. Test rollback, restore, failover, replay, or reprocessing steps where they apply. A reliable runbook names the owner, required evidence, escalation path, and point where rollback is safer than live repair. Retest after meaningful platform, schema, identity, or region changes.
Performance: Performance for Cosmos DB full-text index is measured through query latency, RU charge, relevance score quality, result count, indexing update duration, partition fan-out, and user search completion rate. Tune only after confirming the real bottleneck, because identity, networking, client retries, partition choice, query shape, consistency, or quota can mimic platform slowness. Use baseline metrics before and after every significant change. Test peak load, failure recovery, and representative data rather than happy-path samples. A good performance plan states the target, measurement window, acceptable tradeoff, and rollback trigger so speed improvements do not damage reliability, security, or cost control. Keep the accepted baseline with the change record.
Operations: Operationally, Cosmos DB full-text index needs documented indexed paths, query examples, relevance tests, RU baselines, deployment procedure, rollback plan, and owner review for sensitive text fields. Keep portal location, CLI discovery commands, dashboards, alerts, IaC source, change history, and support ownership close to the runbook. Capture before-and-after evidence with tenant, subscription, resource group, region, owner, timestamp, and environment. Separate read-only inspection from mutating or destructive actions so responders do not improvise under pressure. Good operations make the term searchable, auditable, and explainable across engineering, support, security, and finance handoffs. Store evidence where incident responders can find it without developer access or tribal knowledge during high-pressure incidents.

Common mistakes

Indexing the wrong text path and blaming query syntax.
Rolling out indexing policy changes without measuring write impact.
Ignoring sensitive fields that become easier to search once indexed.