MongoDB & NoSQL Documents to LLMs: JSON vs TOON

Send MongoDB documents to an LLM as TOON when the collection is uniform — same fields per document — and as JSON when it is not. TOON saves 58.8% tokens on flat uniform collections and only 21.9% on mixed structures, so the right answer depends entirely on document shape. Project first, then encode.

Why NoSQL Document Shape Determines Which Format Wins

MongoDB and other NoSQL databases excel at flexible schemas: a single collection can hold documents with wildly different field sets. That flexibility is a strength for storage, but it becomes a liability when serializing documents for an LLM prompt, because token savings from TOON depend entirely on repetition. If every document has the same fields, TOON declares them once in the header and pays zero per-row overhead for keys. If documents differ, the header cannot cover them all, and TOON's advantage shrinks to near zero.

The official toonformat.dev benchmark (5,016 LLM calls, 209 questions, four models) makes this boundary precise. On flat uniform arrays, TOON uses 58.8% fewer tokens than JSON (67,778 vs 164,452 tokens). On e-commerce orders with nested line items, the reduction drops to 33.3%. On mixed structures — documents with varying field sets — it falls to just 21.9% (227,830 vs 291,711 tokens).

That 37-percentage-point spread between best and worst case is the practical guide to every MongoDB-to-LLM decision. The sections below walk through each shape and the correct approach for each. For a broader format comparison across all data shapes, see our TOON format comparison guide.

Uniform Collections: TOON's Sweet Spot

A uniform MongoDB collection is one where every document at the top level shares the same fields: user profiles, product catalog entries, sensor readings, log events, or analytics rows. These are TOON's ideal input. The entire collection maps to a single table block, field names are declared once, and every row is pure values.

The example below uses a small user collection. Three documents as JSON versus the equivalent TOON table:

// JSON — field names repeated on every document (~180 tokens for 3 docs)
[
  { "_id": "u1", "name": "Alice Chen",   "plan": "pro",  "region": "us-west", "active": true  },
  { "_id": "u2", "name": "Bob Martins",  "plan": "free", "region": "eu-west", "active": true  },
  { "_id": "u3", "name": "Carol Davis",  "plan": "pro",  "region": "us-east", "active": false }
]

// TOON — schema declared once, values only per row (~74 tokens for 3 docs, ~59% fewer)
users[3]{_id,name,plan,region,active}:
  u1, Alice Chen,  pro,  us-west, true
  u2, Bob Martins, free, eu-west, true
  u3, Carol Davis, pro,  us-east, false

At scale — 200 user documents — the JSON version repeats each of the five field names 200 times. TOON declares them once. The benchmark's flat/uniform category measured exactly this pattern: 164,452 tokens for JSON versus 67,778 for TOON. That is not a rounding difference; it is the difference between fitting roughly 61 documents or 150 documents in a 10,000-token context budget.

Accuracy is preserved. TOON achieves 99.6% field-retrieval accuracy on uniform data — slightly above JSON — because the explicit header line gives the model an unambiguous schema to validate against. See the TOON format introduction for a detailed explanation of the header syntax.

Nested Documents: Project First, Then Encode

Most real MongoDB collections are not purely flat. An e-commerce order document might contain an embedded array of line items, a nested shipping address, and a payment sub-object. Passing the raw document as TOON saves only 33.3% versus JSON, and the encoding complexity increases substantially.

The better pattern is to project to a flat representation at query time, then encode the projected result as TOON. Use MongoDB's $project stage in an aggregation pipeline to promote nested scalar fields to the top level and exclude sub-arrays the LLM does not need for the current task.

// Raw nested document — TOON saves only ~33% here
{
  "_id": "order_991",
  "customer": { "id": "u1", "name": "Alice Chen" },
  "total": 142.50,
  "status": "shipped",
  "items": [
    { "sku": "A12", "qty": 2, "price": 49.99 },
    { "sku": "B07", "qty": 1, "price": 42.52 }
  ],
  "shipping": { "carrier": "FedEx", "eta": "2026-06-10" }
}

// After $project: flat uniform row — TOON saves ~59% on a collection of these
// db.orders.aggregate([
//   { $project: {
//     order_id: "$_id",
//     customer_id: "$customer.id",
//     customer_name: "$customer.name",
//     total: 1, status: 1,
//     carrier: "$shipping.carrier",
//     eta: "$shipping.eta"
//   }}
// ])

// Result encodes as a clean TOON table:
orders[n]{order_id,customer_id,customer_name,total,status,carrier,eta}:
  order_991, u1, Alice Chen, 142.50, shipped, FedEx, 2026-06-10
  order_992, u2, Bob Martins, 87.00, pending, UPS,   2026-06-12
  ...

The key insight is that the LLM task determines which fields matter. If the task is "summarize recent orders by customer," you need customer_name, total, status, and eta — not the full item array. Dropping the embedded line items both flattens the document and removes data that would distract the model from the actual question.

Document Shape Decision Table: JSON or TOON?

The table below maps document shapes to the recommended format, using figures from the toonformat.dev benchmark and the arXiv 2603.03306 study.

For the full cross-format picture including CSV and YAML, see our JSON vs TOON deep-dive.

Where Deeply Nested Documents Should Stay as JSON

Some MongoDB documents are genuinely irreducible: a medical record with nested arrays of diagnoses, procedures, and medications; a CMS content document with arbitrary block types; a configuration document where each key has different semantics. On this kind of data, the toonformat.dev benchmark measured only 21.9% token savings — and the arXiv 2603.03306 study notes that TOON's efficiency is non-linear, paying off only once cumulative per-row savings amortize the upfront format-instruction overhead.

For these shapes, pass the raw JSON. The model has deeply internalized JSON from training, needs zero format instructions, and can navigate arbitrarily nested structures natively. The 21.9% saving is real but rarely worth the integration cost when your documents do not share a schema.

One alternative worth considering for complex nested data: summarize or extract the relevant sub-fields in a pre-processing step (using a cheap, fast model call or a simple traversal function), then encode the extracted flat summary as TOON. This two-step pattern often recovers most of the token savings even on non-uniform source documents.

Practical Implementation: MongoDB Aggregation to TOON

The full pipeline from MongoDB query to LLM prompt looks like this:

import { MongoClient } from "mongodb";
import { encode } from "@toon-format/toon";

const client = new MongoClient(process.env.MONGO_URI);
const db = client.db("ecommerce");

// 1. Project to flat, uniform fields
const orders = await db.collection("orders").aggregate([
  { $match: { status: "shipped", date: { $gte: new Date("2026-01-01") } } },
  { $project: {
    _id: 0,
    order_id: { $toString: "$_id" },
    customer: "$customer.name",
    total: 1,
    status: 1,
    carrier: "$shipping.carrier",
    eta: "$shipping.eta"
  }},
  { $limit: 50 }
]).toArray();

// 2. Encode the uniform array as TOON
const toonPayload = encode({ orders });

// 3. Build the prompt
const prompt = `You are an order analyst. Answer using only the data below.
${toonPayload}
Question: Which customers have orders arriving after June 10?`;

// 4. Call the LLM
// fetch("https://api.openai.com/v1/chat/completions", { ... })

The $limit: 50 is intentional: send only as many documents as the task requires. Over-fetching is a common mistake that wastes tokens regardless of format. Combine the field projection with a document count limit and you often find that TOON on a 50-document subset is cheaper and more accurate than JSON on 500 documents.

For vector-database retrieval results — which follow the same uniform-array pattern — the companion post on formatting vector DB results as TOON covers the Pinecone and Weaviate integration in detail. The overall cost optimization strategy is covered in the API cost optimization guide.

The Overall Token Reduction on Real MongoDB Workloads

Across all data shapes tested in the toonformat.dev benchmark, TOON achieved an overall 39.9% token reduction versus JSON while maintaining 76.4% retrieval accuracy (versus JSON's 75.0%). That overall figure blends the full range from 21.9% on mixed structures to 58.8% on flat uniform arrays.

For a MongoDB deployment, a realistic workload might be 60% uniform collections (user data, product catalog, analytics), 30% lightly nested documents (orders with projection), and 10% deeply heterogeneous documents (content, configuration). Applying TOON to the first two categories and JSON to the third produces a blended saving in the 45–55% range — meaning roughly half your input token costs on MongoDB-sourced context, with no change in accuracy.

Use the free json2toon converter to paste a sample of your actual collection and see the token count difference before committing to the integration.

Frequently Asked Questions