Moving Azure Cosmos DB for MongoDB Data into Fabric - The Connector and When to Use It
A pattern we see constantly in Australian businesses: the application team, quite sensibly, built the product on a document database. Cosmos DB with the MongoDB API is a common choice because it gives developers the MongoDB model they like with Azure running the infrastructure underneath. It handles the operational load beautifully. Users click around, orders get written, everything is fast. Then the analytics team wants to report on any of it, and hits a wall, because a document database optimised for serving one app is a genuinely awkward thing to run analytics against.
That gap between "the app's database" and "the place we do analytics" is where the Azure Cosmos DB for MongoDB connector in Microsoft Fabric Data Factory earns its place. Microsoft documents it in the connector overview, and the short version is that it lets you pull data out of your Cosmos MongoDB collections and into Fabric, where you can actually model it, join it to everything else, and report on it without hammering the database your customers depend on.
Why you do not just report off the operational database
This is worth spelling out because it trips up a lot of teams. The instinct is reasonable: the data is already in Cosmos, so why copy it, why not point Power BI straight at it and be done.
Two reasons, and both bite in production. The first is load. Your operational database is sized and tuned to serve your application. Analytical queries have a completely different shape: they scan large ranges, aggregate across huge numbers of documents, and do not care about single-record latency. Run those against your live Cosmos instance and you are either burning through request units and paying for it, or you are slowing down the app your customers are using, or both. Analytics and operations want opposite things from a database, and making one serve both usually means it serves neither well.
The second is that a document store is not shaped for analysis. Data in Cosmos MongoDB lives as documents, often deeply nested, with a structure optimised for the app's read and write patterns rather than for joining and aggregating. To report on it properly you want it landed somewhere you can flatten, model, and combine it with data from your other systems. That somewhere is Fabric. The connector is the bridge that gets it there, on a schedule, without the analytics workload ever touching your production database directly.
This separation of the operational and the analytical is one of the most important architectural ideas in modern data work, and it is exactly what our Microsoft Fabric consultants set up for clients who have outgrown reporting straight off their app database.
What the connector actually gives you
Practically, you use this connector inside a Fabric Data Factory pipeline, most often in a copy activity, to move data from your Cosmos DB MongoDB collections into a Fabric destination like a lakehouse or warehouse. You set up a connection to the Cosmos MongoDB endpoint, point at the collections you care about, and the pipeline handles the movement. From there the data sits in Fabric where the rest of your analytics estate lives, ready to be modelled and reported on.
The value is not the copy itself, copying data is not hard. The value is that it plugs your document database into the same platform as everything else, so your Cosmos data can be joined to your finance data, your CRM data, your operational data from other systems, and turned into something a business can actually use. A document database in isolation answers questions about itself. In Fabric, alongside your other sources, it answers questions about the business.
The part that catches people out: schema
Here is where I get honest, because this is where these projects go sideways if you are not careful.
Relational databases have a fixed schema. Every row in a table has the same columns. Document databases do not work that way. Two documents in the same Cosmos collection can have different fields, nested objects several levels deep, arrays of sub-documents, and fields that exist in some records and not others because the app's data model evolved over time. That flexibility is exactly why developers like document stores, and it is exactly what makes them painful to pull into a structured analytics platform.
When you move that data into Fabric, you have to decide how to map documents that do not have a consistent shape onto something you can query with structured tools. How do you flatten a nested object? What do you do with an array of line items inside an order document, split them into their own rows and table, or keep them nested? What happens to a field that only three per cent of your documents have? These are not connector settings you can toggle. They are modelling decisions, and they need someone who understands both the source data and what the business is trying to report on.
We have seen teams treat this as a plumbing job, wire up the connector, dump the collections into a lakehouse, and declare victory. Then the analysts discover the data is an unusable mess of nested structures and inconsistent fields, and the real work, which is the modelling, has not even started. The connector is the easy ten per cent. Understanding your document structure and shaping it into something analysable is the ninety per cent, and it is the bit that determines whether the whole exercise was worth doing.
The other thing to plan for is schema drift over time. Because the app can change its document shape whenever the developers ship a feature, the data you are pulling next quarter might not look like the data you are pulling today. A new field appears, an old one stops being written, a structure changes. Your pipeline and your model need to cope with that without silently breaking or, worse, silently dropping data. That means talking to the application team about how their data model evolves, not just pointing a connector at a collection and walking away. The healthiest projects we run have the app team and the data team actually talking to each other. The painful ones have a data team reverse-engineering document structures the app team could have explained in five minutes.
How we approach it
A few things we do as standard on this kind of work, in case it saves you some pain.
Understand the documents before you build anything. Get real sample documents, look at how they are actually structured, and find out from the app team where the inconsistencies and the historical baggage live. Every hour spent here saves several later.
Land the raw data first, then model in stages. Pull the documents into Fabric in something close to their raw form, then do the flattening and shaping as deliberate transformation steps you can inspect and rerun, rather than trying to do everything in one clever copy activity. When the model needs to change, and it will, you are changing a transformation step, not re-engineering the whole pipeline.
Decide up front what is incremental. Copying entire collections every run is fine while they are small and expensive once they are not. Work out early how you will pull only what has changed, because retrofitting incremental loading onto a pipeline that assumed full copies is a genuine rework job. This is the sort of thing our Microsoft Data Factory consultants sort out at design time rather than after the data volumes have caught up with you.
Where to land on it
The Azure Cosmos DB for MongoDB connector is a good, necessary piece of plumbing, and if you are running an app on Cosmos MongoDB and want to report on that data properly, you will end up using it. It does its job. Just go in with clear eyes about where the actual effort sits, which is not the connector, it is the modelling of document data into something a business can analyse, and the ongoing management of a schema that can shift under you.
If you are staring at a Cosmos database full of your product's data and wondering how to turn it into reporting that the business can trust, that is a well-worn path for us. Have a look at our services or get in touch and we will help you get the data into Fabric in a shape that is actually useful, not just technically present.
Microsoft's connector overview has the current setup steps and supported configurations. The judgement about how to model the document data once it lands is the part that comes from having done it a few times, and it is the part that decides whether the project pays off.