Inspecting Local Data with Azure Cosmos DB Shell

Azure Cosmos DB Shell lets you browse databases, containers and items from the terminal. This walkthrough pairs the shell with the local Azure Cosmos DB Linux Emulator and the FleetCharge sample data to show connecting, navigating, querying and point reads. It is a practical way to check what your application actually stored during development, without opening the portal or adding diagnostic code.

Key points

• Install Shell 1.1.280-preview with dotnet tool install --global CosmosDBShell --prerelease, or use the self-contained ZIP binary.
• The emulator serves the database endpoint on 8081 and readiness on 8080; connect with http://127.0.0.1:8081/.
• Use ls -m 10 to cap listings, and avoid unlimited listings on large containers.
• print current-dispatch SEA-01 should return BAY-2 and print current-dispatch PDX-02 should return BAY-99 on a fresh seed.
• A point read needs both the item ID and the full partition key value; the ID alone is not enough.
• When finished, run cleanup_cosmos to remove your demo database and stop the emulator container.

Microsoft's Azure Cosmos DB Shell lets you browse databases, containers and items from a terminal, without opening the Azure portal or adding temporary diagnostic code. The walkthrough pairs the shell with the local Azure Cosmos DB Linux Emulator running in Docker on port 8081, then uses the seeded FleetCharge dispatch data. It covers connecting, moving through the hierarchy with cd and ls, running queries and reading a single item with print.

The key detail is that a point read needs the full address. The container uses /depotId as its partition key, so the same item ID, current-dispatch, returns different documents for SEA-01 and PDX-02. The emulator is meant for local development only: its well-known key and successful local runs say nothing about production authentication, throughput or resiliency.

Real-world use

• Checking what a dispatch service wrote to Cosmos DB right after a local test run, straight from the terminal.
• Confirming that one document in a specific partition was updated correctly, without writing a query or diagnostic code.
• Investigating why a local test fails by looking at the stored data in the emulator during development.

Why it matters

You can see what is really stored during local development without adding logging code or opening the portal. Remembering that point reads need the full partition key prevents reading the wrong document.

Related stories

• .NET 8 and 9 End of Support: A Deployment-First Migration ChecklistDVDEV Community: #dotnet2 d ago
• Metalama 2027.0 adds interceptors to redirect method calls at build timePMMetalama / PostSharp Blog4 d ago
• Writing executable specifications with Bobcat in C#JMJeremy D. Miller (The Shade Tree Developer)5 d ago