API for NoSQL
- New applications storing JSON documents
- The native API with the widest feature set
- SQL-like queries, change feed and hierarchical keys
Azure Cosmos DB
Azure Cosmos DB consulting and data modeling
In Azure Cosmos DB, one decision sets both query speed and the request unit bill: the partition key. Agnotic Technologies models containers from your real access patterns, then sets the partition key, consistency level, indexing policy and capacity mode so cost follows real use.
API choicePartition key designRequest unit sizingChange feed processing
Trusted by global innovators
Cosmos DB consulting
What does Azure Cosmos DB consulting involve?
Azure Cosmos DB consulting is modeling and tuning Cosmos DB containers around how your application reads and writes. Agnotic Technologies chooses the API, picks a partition key from real access patterns, sizes request units and the capacity mode, sets the consistency level and indexing policy, and designs change feed processing and multi-region writes.
We design new containers and fix existing ones that rate limit, cost more than expected or cannot serve a new feature with their current key.
If your team runs on AWS instead, our Amazon DynamoDB consulting applies the same access-pattern-first method to that service.
API choice
Which Cosmos DB API fits your application?
An account is created for one API, so we settle this before any modeling starts.
API for MongoDB
- Existing MongoDB applications and drivers
- Teams that want MongoDB query syntax
- Server version and feature support checked first
API for Apache Cassandra
- Existing applications written in CQL
- Wide rows read by partition
- Query-first tables, as in Cassandra itself
API for Apache Gremlin
- Graph traversals over related items
- Recommendations and dependency maps
- Partitioning planned around traversal paths
API for Table
- Applications already on Azure Table Storage
- Key-value reads by partition key and row key
- Global distribution without a rewrite
Partition key
How do we choose a partition key?
Every item lives in a logical partition named by its key, and every query and write is cheaper when it stays inside one.
List the access patterns
Each read and write the application makes, with expected volume. Point reads by ID and partition key are the cheapest operation, so we design for as many as we can.
Find a key with many values and even traffic
User ID, tenant ID or device ID usually beat status or date, which pile traffic onto a few partitions.
Check growth against the logical partition limit
One key value can hold only a limited amount of data, so a key that grows without bound, such as a very large tenant, needs a second level.
Add hierarchy where one level is not enough
Hierarchical partition keys, such as tenant, then user, then session, spread a large tenant while queries for one tenant still reach a small set of partitions.
Test with real skew
We load realistic data, including your largest tenants, and read request unit charges and rate limiting per partition before launch.
Consistency
Which consistency level should each workload use?
Stronger levels cost more per read and add latency across regions, so we pick a default for the account and override it per request where a workload needs something different.
01
Strong
Example: An account balance that must never read a stale value
Approach: Reads always return the latest committed write. Used with a single write region, where write latency grows with the distance between regions.
02
Bounded staleness
Example: Stock levels shown in several regions that may lag by a known amount
Approach: Reads lag by no more than a set number of versions or a time interval, whichever is reached first.
03
Session
Example: A user who must see their own profile edits straight away
Approach: The most widely used level: each client session reads its own writes, with read throughput close to eventual.
04
Consistent prefix
Example: An activity feed where order matters but a short delay is fine
Approach: Reads never see writes out of order, though they may be behind.
05
Eventual
Example: Like counts or view totals
Approach: No ordering guarantee and the lowest read cost, for data where a slightly stale value does no harm.
Request unit troubleshooting
Why does Cosmos DB use more request units than expected?
The table we work through when a container rate limits or its bill climbs.
| Symptom | Likely cause | Fix |
|---|---|---|
| Requests fail with status 429 at busy times | Throughput is too low for the peak, or the traffic lands on one partition | Find any hot partition first; then raise throughput, switch to autoscale or change the key |
| One logical partition takes most of the requests | A low-cardinality key such as status or country, or one very large tenant | Move to a key with more distinct values, or to a hierarchical partition key |
| Queries cost far more than point reads | Queries without the partition key fan out across every physical partition | Filter on the partition key, or keep a copy of the data keyed for that query |
| Writes cost more than expected | The default indexing policy indexes every property of every item | Exclude paths that are never filtered or sorted, and add composite indexes only for real ORDER BY patterns |
| Change feed consumers fall behind | Too few processor instances, or slow work done inside the handler | Scale out processor instances, keep the handler small and push slow work to a queue |
| Large items read just to show a few fields | Arrays inside items keep growing as data is appended | Split growing arrays into separate items under the same partition key |
Every fix is checked against the request charge returned with each response, so the saving is measured, not assumed.
Events and regions
Change feed, regions and access design
The features that shape the rest of the system around Cosmos DB.
Change feed
- Materialized views keyed for other queries
- Events published to Azure Service Bus or Event Hubs
- Search and analytics copies kept in sync
- Checkpoints so a restart resumes where it stopped
Deletes and TTL
- Latest version mode carries inserts and updates only
- A soft-delete flag plus TTL so consumers see removals
- All versions and deletes mode where the account supports it
Multi-region
- Read regions close to users
- Multi-region writes only where local writes are needed
- Last writer wins on a timestamp, or a custom merge procedure
- Failover priority and rehearsed region outages
Access
- Microsoft Entra ID role-based access to data
- Key-based authentication turned off where possible
- Private endpoints and network rules
- Customer-managed keys when policy requires them
Which workloads fit Azure Cosmos DB?
Multi-tenant SaaS data
Tenant-scoped partition keys, with hierarchical keys for the few tenants that grow large.
Global consumer apps
Profiles, carts and preferences read close to the user in several Azure regions.
Device and telemetry data
Readings keyed by device, with TTL removing old data without a cleanup job.
Event-driven systems
The change feed drives projections and integrations from one source of truth.
Startups building on Azure
Azure Cosmos DB for startups often starts in serverless mode, paying for request units used, with provisioned or autoscale throughput once traffic is steady.
References
Azure Cosmos DB documentation we design against
PartitioningRequest unitsConsistency levelsChange feedAzure Well-Architected Framework
Facts and sources
Facts from the Azure Cosmos DB documentation
Limits and behaviors from Microsoft Learn that decide the keys, capacity and pipelines we design.
Azure Cosmos DB offers five consistency levels, from strongest to weakest: strong, bounded staleness, session, consistent prefix and eventual. For the same request units, read throughput at strong and bounded staleness is half that of the other three.
Source: Microsoft Learn: consistency levels in Azure Cosmos DBEach logical partition in an Azure Cosmos DB container can store up to 20 GB of data, and there is no limit to the number of logical partitions in a container.
Source: Microsoft Learn: partitioning and horizontal scaling in Azure Cosmos DBAzure Cosmos DB measures every write, point read and query in request units; reading a single item of about 1 KB by its ID and partition key uses one request unit.
Source: Microsoft Learn: request units in Azure Cosmos DBThe Azure Cosmos DB change feed is a persistent record of changes to a container in the order they occur; delete operations and TTL expirations appear only in all versions and deletes mode.
Source: Microsoft Learn: change feed in Azure Cosmos DBHierarchical partition keys let an Azure Cosmos DB container use up to three levels of partition key, so a single top-level value such as one tenant can grow past 20 GB.
Source: Microsoft Learn: hierarchical partition keys in Azure Cosmos DB
Engagement
How does a Cosmos DB engagement run?
1.
Model review
We read your access patterns, containers, request unit metrics and 429 counts, and list what drives cost or blocks new features.
Model2.
Design and move
New partition keys, indexing policy and consistency settings, with data copied to a new container and a switch the application controls.
Move3.
Tune and hand over
Throughput limits, alerts on rate limiting and hot partitions, and a runbook your team can follow.
OperateFrequently Asked Questions
Scope sets the length: the number of containers, the access patterns behind them, and whether existing data has to be copied to a new partition key. The model review comes first, and we plan the rest from what it finds.
Not in place. We create a new container with the new key and copy the data into it, often through the change feed so writes keep flowing, and the application switches over once counts match.
We do not quote prices. Cost comes from request units, as provisioned throughput, autoscale maximums or serverless use, plus storage and extra regions, at Microsoft's published rates. We estimate it from your real request charges.
Choose Cosmos DB when the main reads are known lookups by key at high scale or across regions. Choose Azure SQL Database when the product depends on joins, ad hoc reporting and strict relational integrity. Some systems use both.
Serverless suits low or spiky traffic, because you pay for the request units used. Provisioned or autoscale throughput suits steady production traffic that needs predictable latency. We decide from your expected request pattern.
Yes. Change feed processors keep search indexes and other stores in sync, and Microsoft now recommends mirroring Azure Cosmos DB into Microsoft Fabric for analytics instead of Synapse Link for new projects.