The management of Nordlicht Reisen GmbH (invented client, F-07) wants to know how many appointments are booked and canceled per office and month. The figures are in the activity feed events and in appointments (F-03). Cosmos DB is the wrong place for this: a query across all partitions with aggregates costs many RU and can disturb the offices' work. Learn names two ways to separate the analysis from it. This lesson chooses one and checks what has to hold for it.

Not run against Azure and not run against Fabric: no Fabric workspace, no capacity and no account were available. The C# code is compiled with Microsoft.Azure.Cosmos 3.64.0 and was run locally (check of the prerequisites, JSON evaluation). T-SQL and Scala are not compiled and not validated. This lesson changes none of the facts F-01 to F-08.

Two ways

Mirroring Cosmos DB in Fabric
What it is your Azure account stays, its data is copied to OneLake continuously a database of the same engine, entirely in Fabric
Where the application writes still in Azure Cosmos DB in the Fabric database
Billing Azure account as before; queries in Fabric count against the capacity in capacity units (CU) of the Fabric capacity
Sign-in Entra or key (restrictions below) Entra only, no keys
Management all settings of the Azure service simplified, defaults

Both need Fabric and a workspace; turning on mirroring requires the Admin or Member role there. For Cosmos DB in Fabric, Learn names Power BI Premium, a Fabric capacity or a trial capacity as the license. Prices are not given here; cost drivers are the capacity (queries in Fabric count against it, the replication itself does not, according to Learn) and the continuous backup of the account. Learn says the Synapse link can no longer be used for new projects.

The choice for the Kladde. The account cosmos-kladde exists and already runs without keys (F-01); Kladde.Verlauf writes there. Cosmos DB in Fabric would mean changing the database, and according to Learn it knows neither Private Link nor customer-managed keys, at most 25 containers per database, no stored procedures, and SDK containers must be created with autoscale. Therefore: mirroring of the existing account. What would tip the choice: a new project without legacy, which wants to save on management, works in Fabric and needs none of these limits.