Skip to content

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.