Azure Cosmos DB Emulator and Production Account: Partition Key and Consistency Interoperability

Designing an application against Azure Cosmos DB requires understanding where the local emulator and a provisioned production account diverge. The emulator defaults to Session consistency, while production accounts support Strong, BoundedStaleness, Session, ConsistentPrefix, and Eventual consistency. The emulator may also handle partition key routing differently, potentially accepting query patterns that a production account enforces more strictly, and it does not fully replicate production network isolation or request unit throttling behavior.

The uncertainty is whether these differences are documented development conveniences or behavioral gaps that demand separate validation. A query pattern or consistency setting validated locally might behave differently once deployed, but the exact boundary between supported emulator behavior and production enforcement is not always clear.

Assuming the Core (SQL) API and a current emulator release, are partition key routing requirements and consistency guarantees enforced identically across both environments? Which specific divergences—such as cross-partition query limits or RU consumption patterns—are known to differ and require explicit production testing? What verification approach confirms that a locally validated configuration will maintain the same routing and consistency constraints in a production account?