How MongoDB Defines the Raw Data Contract

July 2026

For MongoDB, raw data is the JSON representation of documents from one collection, not an implied relational model hidden behind the collection.

Short Answer

The raw data contract for MongoDB is the document shape from one selected collection, converted from BSON to JSON for downstream use. Skippr reads a named database and collection, so the raw layer is whatever those documents look like after that BSON-to-JSON conversion, namespaced as mongodb.{database}.{collection}.

That keeps the contract grounded in the collection itself. If orders documents contain nested address objects, arrays of line items, and an _id for document identity, that nested structure is still part of the raw contract. If you add a filter to read only active orders, the contract becomes that filtered document subset rather than the entire collection.

Why Teams Struggle with This

Teams struggle with MongoDB when they assume the raw layer should already look relational. A collection can be an excellent source contract, but only if everyone accepts that the collection document is the record shape, not a half-finished SQL table waiting to be flattened.

• The selected database and collection define the boundary more clearly than any downstream model ever will.
• An optional filter narrows the contract and should be treated as part of the source definition, not as a temporary tweak.
• BSON-to-JSON conversion is helpful, but it still means nested documents and arrays remain real parts of the raw shape.
• Batch reads and change-stream CDC are related but different; the first gives you documents, the second adds mutation timing later.

How Skippr Handles It

Skippr keeps MongoDB readable because the connector only needs connection_string, database, collection, and optional filter. That is enough to make one collection a clear contract instead of turning the raw layer into a vague export of an entire cluster.

The namespace pattern helps with lineage too. When a downstream raw table came from mongodb.app.orders, there is very little doubt about which collection defined the incoming document shape.

• Reads one MongoDB collection directly and converts BSON to JSON.
• Supports an optional filter document when the collection is too broad as-is.
• Uses the namespace mongodb.{database}.{collection} for clear raw lineage.
• Can later extend into change-stream CDC without changing the underlying collection contract.

What the First Useful Version Looks Like

The first useful version is one collection such as orders, one sample of nested documents, and one decision about whether the full collection or a filtered subset belongs in the raw layer. That is enough to avoid months of ambiguity.

If the collection is already a stable application boundary, do not over-model it at the source. Let Skippr preserve that document contract cleanly, then handle analyst-facing reshaping farther downstream.