Azure Cosmos DB Emulator limits: which behaviors still require a real account for integration tests?

Goal

I want to run integration tests for an application using the Azure Cosmos DB NoSQL API without production credentials, relying on the documented Azure Cosmos DB Emulator with its well-known key on localhost. The open decision is whether emulator-only testing is sufficient, or whether some test cases must still target a real dev-tier account.

Constraints and uncertainty

The emulator is documented as not replicating all cloud behaviors: multi-region replication, consistency-level tuning, and throughput semantics at scale differ or are unsupported. It also enforces its own practical limits, such as a cap on the number of containers and fixed local storage, which differ from cloud limits. Our CI runs on Linux agents, and the Linux container image of the emulator has historically lagged the Windows version in feature parity.

Our test suite exercises the change feed, TTL expiry, and queries with custom indexing policies, and it is unclear which of these the emulator version we would pin actually supports.

Questions

• Which specific NoSQL API behaviors (change feed, TTL, indexing policy edge cases, consistency levels) are documented as unsupported or divergent in the current emulator release?
• Are the emulator's container-count and storage limits configurable, and do they risk false failures for tests that would pass in production?
• Is the Linux emulator container currently supported for CI use at parity with the Windows emulator, or should pipelines plan around Windows agents?