Context

PYTHON-527 (2013, closed Won't Fix 2017) rejected using libbson in _cbsonmodule/_cmessagemodule due to packaging complexity and the assertion that libbson wouldn't help since the real cost is Python↔C string/object conversion. A 2026 spike (results: https://gist.github.com/blink1073/12e2464fb70e7e85339dc68344d4dec6) tested that claim: a properly-written libbson C extension reaches performance parity with _cbsonmodule.c. The packaging objection still stands. Takeaway: performance is no longer a blocker, but adoption isn't currently recommended.

Definition of done

Spike complete: correctness-verified prototype, benchmarks vs _cbson/pure-Python, and a documented recommendation (linked above). No code changes needed to close this. Re-open only if there's an independent reason to want libbson.

Pitfalls

• Naive ports will reproduce the old slowdown unless they use exact-type dispatch and avoid PyDict_SetItemString/format-string constructors (see gist).
• This would be PyMongo's first external C dependency; needs a vendoring/binary-distribution strategy across all wheel targets.
• Prototype doesn't cover Decimal128, DBPointer, codec options, or raw-batch helpers — real integration must close that gap.
• libbson 1.x/2.x ABI differences already broke {{python-bsonjs }}compatibility once in this spike.