Bohdan Kontsedal
Builds Monghoul
I build Monghoul, a MongoDB IDE for the desktop. I write here about the parts of MongoDB that cost me time: query plans that look fine and are not, schema choices that only show their price at scale, and the gap between what the documentation says and what the server does on the version you are actually running. Everything with a number in it comes from a run you can reproduce, and the script is published with it.
Written by Bohdan Kontsedal
- What a MongoDB MCP server can reach, before you point one at production The official server writes unless you pass --readOnly, its confirmations depend on the client supporting elicitation, and its Atlas tools create users.
- Monghoul against DataGrip DataGrip measured against Monghoul on one machine: 2,766.6 MB against 106 MB on disk, 3.53 s against 0.07 s to a window, 1,194 MB before a project is open.
- Monghoul against NoSQLBooster NoSQLBooster measured against Monghoul on one machine: 455 MB against 106 MB on disk, 0.71 s against 0.07 s to a window, 585 MB against 398 MB of memory.
- Monghoul against Studio 3T Studio 3T measured against Monghoul on one machine: 415 MB against 106 MB on disk, 5.23 s against 0.07 s to a window, 626 MB against 398 MB of memory.
- Monghoul against TablePlus TablePlus measured against Monghoul on one machine: 422 MB against 106 MB on disk, 0.78 s against 0.07 s to a window, and 59 MB of memory against our 398.
- What each MongoDB release added to the aggregation language, from 5.0 on The answer to "why does $percentile not work" is almost always the server version. Here is what arrived in each release from 5.0 to 8.3.
- The 100 MB aggregation limit stopped failing your query in MongoDB 6.0 Most guides say a stage over 100 MB errors unless you pass allowDiskUse. That has been wrong since MongoDB 6.0, and the new failure is quiet.
- BSONObjectTooLarge, and the field that is actually costing you the space The 16 MB limit is on the encoded document, not on what you think you stored. The usual culprit is an array nobody bounded.
- Extended JSON, and where $date and $oid quietly change your data JSON has no date type and no 64-bit integer. Extended JSON has both, in two modes, and relaxed mode loses less than people think and more than they check.
- A compound index in the wrong order is a sort you did not ask for The same three fields in a different order decides whether the index serves your sort or the server does it in memory. The plan says which you have.
- Your query uses an index and is still slow An IXSCAN in the plan is not the finish line. The number that matters is how many documents the server had to read to return the ones you asked for.
- $lookup against embedding, measured on 10 million documents A $lookup on an indexed key cost nothing here. Sorting on the joined field cost nine seconds. The gap between those two is the whole decision.
- Monghoul against MongoDB Compass MongoDB Compass measured against Monghoul on one machine: 651 MB against 106 MB on disk, 1.26 s against 0.07 s to a window, 321 MB against 398 MB of memory.
- Read-only MongoDB access for an AI agent, and what still gets through A read-only flag that works by reading the query text can be walked past in four lines. Where the check runs matters more than what it is called.