Cosmos DB for Table - Azure Glossary

Understand the concept

In plain English

Cosmos DB for Table means the Cosmos DB API for structured key-value data stored as table entities identified by partition key and row key. In Cosmos DB, it appears when teams need scalable table-style storage for device registries, profiles, reference data, audit events, or applications using Azure Table APIs. It controls table creation, entity shape, PartitionKey and RowKey access, automatic indexing, throughput, consistency, global distribution, and SDK compatibility. 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 for Table matters because simple key-value and tabular workloads can scale well when partition and row keys match real lookup patterns. It turns an abstract database concept into something teams can operate, secure, recover, and explain. If misunderstood, teams can face hot partitions, slow scans, unexpected RU use, incompatible Table Storage assumptions, weak access control, and entity designs that require expensive queries. 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 for Table uses a Cosmos DB account with Table capability, tables, entities, flexible properties, partition and row keys, table SDKs, and managed Cosmos DB platform features. Configure it through account capabilities, table commands, SDK clients, partition strategy, throughput settings, networking, consistency, and application connection strings. Verify with table lists, table properties, entity queries, throughput output, partition-key distribution, SDK logs, RU metrics, and account settings. Key choices include partition key values, row keys, entity properties, throughput, consistency, region layout, automatic indexing, network access, and backup policy. Capture scope, region, identity, capacity, backup state, owner, and rollback trigger.

Exam context

Compare with

Table Storage Cosmos DB API for NoSQL Cosmos DB for Apache Cassandra

Where it is used

Where you see it

In the Azure portal, Cosmos DB for Table appears near Table account overview, Data Explorer tables, entity views; operators confirm scope, environment, readiness, and whether it belongs to production today.
In CLI, SDK, or IaC output, Cosmos DB for Table appears through account capabilities, table list output, table names; those fields create repeatable review evidence for audits, incidents, handoffs, and pull requests.
In monitoring and support work, Cosmos DB for Table appears beside point lookup latency, 429 throttling, hot partitions; those signals connect symptoms to security, reliability, cost, and performance.

Common situations

teams need scalable table-style storage for device registries, profiles, reference data, audit events, or applications using Azure Table APIs.
simple key-value and tabular workloads can scale well when partition and row keys match real lookup patterns.
Use production evidence for Cosmos DB for Table during architecture reviews, incidents, and support handoffs.
Connect Cosmos DB for Table 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 Device registry lookup Scenario, objectives, solution, measured impact, and takeaway.

Scenario

VoltEdge Utilities needed a scalable registry for millions of smart devices with fast lookups by service territory and device id.

Goals

Store 8 million device records
Keep device lookup latency under 40 milliseconds
Use familiar Table API client patterns
Track RU cost by service territory

Approach using Cosmos DB for Table

Engineers used Cosmos DB for Table with PartitionKey set to service territory and RowKey set to device id. Device metadata, firmware status, and installation attributes were stored as flexible entity properties. The team validated partition distribution before importing the full registry and added autoscale throughput for enrollment bursts. Existing Table SDK patterns were retained with updated connection settings. Dashboards tracked RU consumption, hot partitions, and point lookup latency by territory. Operations documented CLI checks for table inventory and throughput so support could diagnose throttling without guessing from application logs. The team also added owner approval, validation evidence, and post-release monitoring for the device registry lookup workflow. Support notes captured rollback triggers, dashboard links, and escalation contacts so responders could act without tribal knowledge.

Potential outcomes

The registry stored 8.4 million devices after import
Point lookup P95 latency averaged 27 milliseconds
Enrollment bursts completed without manual scaling
Territory-level RU attribution covered 96 percent of monthly spend

What to learn

Cosmos DB for Table is effective for large key-value registries when PartitionKey and RowKey match real lookup patterns.

Scenario 02 Retail session state store Scenario, objectives, solution, measured impact, and takeaway.

Scenario

UrbanCart Retail wanted a simple, globally available store for web session preferences and checkout hints.

Goals

Reduce session lookup latency below 35 milliseconds
Avoid schema migrations for preference changes
Keep checkout hints isolated from customer profile writes
Preserve compatibility with existing Table SDK code

Approach using Cosmos DB for Table

The application team placed session preference entities in Cosmos DB for Table using customer region as PartitionKey and session id as RowKey. Flexible properties allowed new preference flags without schema migrations. Checkout hints were written to a separate table so short-lived session data did not interfere with long-lived profile records. Autoscale handled promotion traffic, while Azure Monitor tracked RU, throttling, and entity size. Developers retained much of their Table SDK code and adjusted retry policies for Cosmos DB behavior. The runbook documented cleanup jobs for expired sessions and read-only CLI commands for support. The team also added owner approval, validation evidence, and post-release monitoring for the retail session state store workflow. Support notes captured rollback triggers, dashboard links, and escalation contacts so responders could act without tribal knowledge.

Potential outcomes

Session lookup P95 latency reached 24 milliseconds
Three preference changes shipped without schema migration work
Promotion-week throttling stayed below the alert threshold
Existing client-code changes were limited to configuration and retry settings

What to learn

Table API compatibility can speed modernization when entity design and retention rules are still treated as architecture decisions.

Scenario 03 Permit audit event table Scenario, objectives, solution, measured impact, and takeaway.

Scenario

GovWorks Digital needed a durable event table for permit workflow actions across multiple city departments.

Goals

Capture 20 million audit events per year
Query events quickly by department and permit id
Limit write access to approved workflow services
Keep audit storage costs predictable

Approach using Cosmos DB for Table

The solution used Cosmos DB for Table to store audit entities with department as PartitionKey and permit-event sequence as RowKey. Workflow services wrote immutable event records through private endpoints, while auditors used a controlled portal for bounded queries. Entity properties captured actor, action, timestamp, and review status. Throughput was sized for business-hour peaks and monitored for hot departments. Retention and export processes moved older data to lower-cost analytics storage after the required review window. CLI runbooks captured table names, throughput, account regions, and network configuration for audit evidence. The team also added owner approval, validation evidence, and post-release monitoring for the permit audit event table workflow. Support notes captured rollback triggers, dashboard links, and escalation contacts so responders could act without tribal knowledge.

Potential outcomes

The platform handled 22 million events in the first year
Auditor queries by department completed under 60 milliseconds P95
Unapproved write paths were blocked by network and access controls
Storage exports kept monthly spend within the approved budget

What to learn

Cosmos DB for Table supports audit-style workloads when key design, immutability, and retention are planned together.

Azure CLI

Use CLI to verify table scope, account capability, and throughput before tuning Table API applications or migrations.

Useful for

Inventory tables for support and ownership reviews.
Confirm throughput settings before troubleshooting throttling.
Capture account capability and region evidence during Table API migrations.

Before you run a command

Confirm account name, resource group, table name, and environment.
Use read-only table commands before throughput or delete changes.
Coordinate key-design changes with application owners and SDK teams.

What the output tells you

Table list output shows which table resources exist.
Throughput output connects capacity to throttling and cost symptoms.
Account output confirms Table capability, regions, consistency, and networking.

Mapped commands

Cosmos DB for Table CLI checks

direct

az cosmosdb create --name <account> --resource-group <resource-group> --capabilities EnableTable

az cosmosdbprovisionDatabases

az cosmosdb table list --account-name <account> --resource-group <resource-group>

az cosmosdb tablediscoverDatabases

az cosmosdb table show --account-name <account> --resource-group <resource-group> --name <table>

az cosmosdb tablediscoverDatabases

az cosmosdb table throughput show --account-name <account> --resource-group <resource-group> --name <table>

az cosmosdb table throughputdiscoverDatabases

Architecture context

Cosmos DB for Table fits architectures that use the Azure Table model but need Cosmos DB capabilities such as global distribution, lower-latency scale, premium throughput behavior, or richer account governance. I review it around PartitionKey and RowKey design, entity size, query filters, RU consumption, SDK compatibility, and migration from Azure Table Storage. The data model is simple, but poor partitioning quickly turns into hot keys and slow queries. Teams should decide whether this API is being used for operational lookups, telemetry, device state, user metadata, or compatibility with an existing table application. Operators need clear account, database, table, throughput, region, backup, firewall, and private endpoint evidence. The best designs keep the table-access contract familiar while modernizing scale and governance.

Security: Security for Cosmos DB for Table starts with knowing which clients, keys, identities, and network paths can read or write table entities and whether entity data contains sensitive fields. 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 for Table comes from request units, entity storage, autoscale peaks, regions, backups, monitoring, and scans caused by weak partition-key or row-key choices. 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 for Table depends on partition-key distribution, throughput headroom, SDK retries, regional settings, backup mode, and application behavior during throttling or failover. 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 for Table is measured through point lookup latency, query RU charge, partition distribution, throttling rate, entity size, SDK retries, and region-to-client distance. 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 for Table needs table inventory, key-design documentation, throughput dashboards, SDK connection records, data retention decisions, and owner-approved schema changes. 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

Using low-cardinality partition keys that create hot partitions.
Running broad scans when point lookups should use PartitionKey and RowKey.
Assuming Azure Table Storage limits and Cosmos DB behavior are identical.