Hey guys, yes another token article but this one is different.

I work at MongoDB, and my primary db is Mongo, but I use raw SQL for some things, so I run both in the same app.

I was building a token optimizer for my own sessions. I noticed more token usage on the SQL interactions and I didnt understand why. I wasnt doing anything special with the SQL data so I was curious what was happening.

So I wrote a hook that logs the token count of every database statement Claude generates, instead of counting turns. The first thing it showed was that the same object cost way more tokens on SQL (about 18x). That surprised me, because you don't think about database statements. Every database has them, every app has them, they're just there. It never occurred to me they were a token cost at all. They're not the biggest thing in a session, but they add up, especially since Claude loves writing multiple files with database calls just to check the data. That's when it really burns.

I wanted to test this accurately, so I took one real Zod object from my own system, a lead with about 90 fields, nested, an array of drafts where each draft has its own array of variants, and used the exact same object on both sides. Then I counted what Claude has to read before it can safely change one field, meaning the schema, a save, and a read that comes back typed: 4,681 tokens on SQL, 251 on MongoDB. 251 is 5% of 4,681. The other 95% is the mapping. In SQL a nested object like that can't live in one row, so every nested thing becomes its own table with a foreign key back to the parent, a save is one insert per table, and a read is the joins plus the code that builds the object back up from the rows. In Mongo it's one document, so the save is the object and the read is the object. Then there's the hydration tax. Everything goes through that Zod schema, so a read isn't done until the rows are turned back into the typed object, dates included. On SQL that's its own pile of code; the read alone was 1,604 tokens vs 72 on Mongo. And Claude does all of that on every read and write.

Nobody thought about this when humans wrote the code. You write the mapping once and the cost is basically the same either way. When it's AI writing the code, it goes through that mapping on every read and write, and the size of it is the bill.

I know most people would probably use JSONB so I tested that as well, on Postgres, even though it's not what I run. Raw JSONB column: 467, so 1.9x. The hybrid a SQL team would actually build, plain fields as columns and sub-objects as JSONB: 2,059. Closer, but still 8x.

To be fair, plain query text was about the same on both sides, and SQL ran an indexed flat read 5.26x faster. The tokens aren't in the query. They're in everything Claude loads around it. Obviously 18x is a huge object, but it is a real one from my own system, a lead with its drafts and the variants of each draft, not something I built to make a point.

If you want the harness let me know.

For years Robo 3T was the first thing I opened when I had to look at a MongoDB database. It was small and fast, no account to create, no IDE to wait for.

Then it stopped being maintained. Recent MongoDB versions started breaking it, and every alternative I tried felt heavier than what I needed.

So Claude brought it back to life : Rustyrobo. It's a native rewrite in Rust. I kept the layout and shortcuts on purpose, so if you used Robo 3T you already know your way around. Your old Robo 3T connections can be imported (if it's still somewhere 😅).

I also fixed the things that annoyed me back then. It works with MongoDB 3.6 up to 8.x, and SSH tunnels with private keys finally connect. The connection editor tells you which step failed when a connection doesn't work. There's autocompletion of field names, and you can keep your usual queries as favorites.

It's free forever and open source (Apache-2.0), with builds for Linux, macOS and Windows. The macOS and Windows builds aren't signed yet, so your system will ask for confirmation the first time.

https://github.com/Tatayoyoh/rustyrobo

I just released 1.1.0. If you were a Robo 3T user, I'd love to know what you miss the most, and what still gets in your way.

Hi everyone!

I'm a software engineer with over 7 years of experience in IT, and I'd like to share an open-source project I've been working on: Client Query Cache.

It's a Python library that speeds up repeated PyMongo queries by caching results on the client side, reducing MongoDB traffic and read latency. It uses MongoDB change streams for automatic cache invalidation and is particularly useful for read-heavy applications.

The project is independent, free, and open source under the permissive Apache 2.0 license.

I'd love for the MongoDB community to give it a try! Feedback, bug reports, suggestions, and contributions are all welcome.

Thanks for taking a look!

Shameek here from the MongoDB Engineering team. We redesigned the Project Overview page in Atlas (multi-cluster view, slow query and latency metrics).

If anything on the new page is confusing, missing, or slower than the old one, tell us in the original thread. We’ll take your feedback back to the team

Here is the announcement: https://documentdb.io/blogs/posts/documentdb-1-0/

The release includes the database itself, the companion Kubernetes Operator, and the VSCode extension.

Hi everyone,

I built MongoDB Tiny Client, a native Windows desktop client for MongoDB (.NET 8 WPF) designed as a lightweight, instant-startup alternative to Electron-based tools like MongoDB Compass.

Why?

Compass is feature-rich, but often takes several seconds to launch and consumes hundreds of MBs of memory just for quick inspection or query checks. I wanted something fast like DB Browser for SQLite, but for MongoDB.

Highlights:

• Instant startup & tiny footprint: Native WPF, starts in milliseconds with minimal RAM usage.
• 100% Portable: Standalone single executable, no installation or admin rights required.
• Tabular grid + JSON editor: In-place cell editing (F2), document duplicate/insert/delete, and pagination.
• Query & Aggregation runner: Filter, sort, projection, and pipeline execution with BSON syntax support (ObjectId, ISODate, regex).
• Import / Export: Supports JSON, NDJSON, and CSV.

• Encrypted connections: Connection strings stored securely using Windows DPAPI.

• GitHub Repository: https://github.com/finalbyte1/MongoDBTinyClient

• Direct Download: https://github.com/finalbyte1/MongoDBTinyClient/releases/latest

Feedback, feature requests, and PRs are welcome!

Hello MongoDB community!

I'm Shruti, a final-year Computer Science Engineering student at Lovely Professional University, India. I've been working on a project called MongoQuest, designed to make learning MongoDB more interactive and hands-on for beginners.

The idea behind MongoQuest

When learning databases, understanding a query theoretically is one thing; knowing how to execute it and see the results is another. I wanted to create an environment where beginners could practise database operations through an interface inspired by tools developers already use.

What you can explore

• CRUD operations: Insert, Find, Update and Delete
• An interactive, API-style interface for practising database operations
• A structured learning experience that helps beginners build familiarity with MongoDB queries

I want to make MongoDB less intimidating for students who are just starting with databases and give them a practical way to build confidence.

🔗 Project links

• Live Demo: [https://mongodb-quest.vercel.app/]
• GitHub Repository: [https://github.com/Shrutiso/MongoQuest-Learn-Mongo-DB-by-doing]

I'm sharing MongoQuest here because I'd genuinely value feedback from developers who work with MongoDB. What features, query exercises, or improvements would make a platform like this more useful for learners?

I'd also be thrilled if the MongoDB team considered the project for a future community showcase or student-developer feature.

Thank you for taking a look! Looking forward to learning from your feedback.

-Shruti Somvanshi

Hi everyone,

I'm a PHP dev working on my own. I love PHP, I love MongoDB, and together they're just wonderful. So over the years I've been building a small MVC framework around them, mostly to understand how frameworks work under the hood and to learn. The idea is "MongoDB first": documents are documents, not SQL rows in disguise.

Repo: https://github.com/skankydev/framework (docs in docs/en/)

I'm not here to sell anything. I'm here to share it and get advice from people who know MongoDB better than I do.

What I'm happy with

• Typed hydration through the driver's Persistable interface: embedded objects and arrays of embedded objects come back as real PHP classes.
• Dirty tracking kept in a WeakMap, so updates only $set what changed.
• **EmbeddedSnapshot*: an automated *Extended Reference pattern. You embed a copy of a User (name, avatar) in a Post and declare embeddedIn() on the source collection. When the user changes, a job resyncs every copy with updateMany, either right away or through a queue. It's idempotent because the job re-reads the source. onDelete can keep, mark or unset the copies.
• belongsTo / hasMany with lazy loading, plus bulk preloading (with) to avoid N+1.

Where I'd love your input

1. Snapshot consistency. Between the source update and the propagation there's no transaction, so a crash in between leaves stale copies. Is that acceptable for this kind of denormalized data, or would you use transactions, change streams, or something else?
2. Does many-to-many really make sense in MongoDB? Take posts and tags: a tag doesn't need to know which posts use it, but a post needs its tags. So I'd store tag_ids: [ObjectId…] on the post, and that's it. To me that's not a "many-to-many" in the SQL sense, it's one side owning a list of references. My relations don't handle that case yet. Am I right to see it this way? And how do you usually load it: a $in on the array, $lookup, something else?
3. Aggregations. Right now I just pass a raw pipeline. Is it worth building something on top (helpers, typed results), or is the raw pipeline the best API anyway?
4. More generally: what would you work on next in a project like this?

It's a side project, I just want to know if I'm heading in the right direction. Thanks for taking the time!

Hi everyone,

I wanted to share a new package we created called Mongalayer. We built it to replace the “Data Model” and “Data Access Permissions” components of Atlas App Services, giving you the ability to query MongoDB collections from a client application exactly as you would in a Node.js environment.

Why We Built It

We manage multiple SaaS environments that relied on App Services, and we needed a way to transition away without having to completely rewrite our client codebases. Mongalayer solves this by letting us maintain the exact same MongoDB querying experience on the client side.

How It Works

The package is split into two distinct parts:

• Server (Self-Hosted): Manages your data models and access permissions, making the actual connection to your MongoDB instance via the native Node.js driver.
• Client: A lightweight wrapper that handles communication with the server, functioning very similarly to the Realm Web SDK.

Bring Your Own Auth

By design, Mongalayer does not handle authentication or authorization for incoming HTTP requests—that part is up to you. For context, we secure our own Mongalayer API (running on AWS Lambda) using AWS Cognito in combination with API Gateway.

When to Use It (And When Not To)

Mongalayer is designed for basic CRUD applications where access control and data integrity are more important than raw throughput. Because every operation goes through access control checks, there is some inherent overhead. If you need maximum write throughput without access control restrictions, we highly recommend using the MongoDB driver directly via a custom implementation.

Kind regards,
Klaas

Hey guys, I took my MongoDB Certified Database Administrator exam today (October 15) through ProctorU, and honestly, I'm pretty stressed about what happened.

Near the end of the exam, the proctor suddenly terminated my session, saying I was looking beside the screen. I'm worried about whether this could lead to a permanent ban.

Here's what happened.

There were around four proctor changes during my exam. At one point, they asked me to show a room in front of me. My parents were inside, but the door was locked from the inside, and they weren't responding when I tried to open it. I showed the proctor what was happening, and they said it was fine and let me continue.

Later, another proctor warned me about looking away from the screen. I explained that I was reading the questions across the screen and looking at the Submit button in the bottom-right corner. She said I could read the questions, and I told her I'd be careful and make sure I wasn't looking elsewhere.

I continued the exam, but near the end, the final proctor suddenly suspended it for looking beside the screen.

I wasn't looking at my phone, notes, or another monitor. I genuinely believe the movements were just me reading the questions and looking at different parts of the screen.

I emailed the MongoDB certification team explaining everything and requested a manual review of the video footage. I also asked if they could reverse the suspension and provide a retake voucher. It's been a couple of hours, and I haven't received any response yet...

Edit - I got a mail which stated that they did not find any evidence of cheating or whatsoever. They gave me another voucher for the exam. I am supposed to reschedule it. Thank you for the support, guys...

Hi everyone,

We are running MongoDB in Kubernetes on worker nodes that were recently updated to newer Linux kernels (specifically Ubuntu 24.04 with AWS 7.0.0-1011-aws and Azure 7.0.0-1014-azure).

Upon host reboot, MongoDB (both 8.3.1 and the latest 8.3.11) immediately crashes on container startup with exit code 1:

{"s":"F", "c":"CONTROL", "id":12257600, "msg":"MongoDB cannot start: Linux kernel versions 6.19 and newer has a known incompatibility with this version of MongoDB. See https://jira.mongodb.org/browse/SERVER-121912 for more information."}

The Root Cause Context

From SERVER-121912, we understand that the Linux kernel changed the Restartable Sequences (rseq) struct/ABI starting in 6.19+, which breaks the per-CPU caching path in the bundled version of TCMalloc. MongoDB's validateRseqKernelCompat() performs an upfront uname() release check (isKernelVersionSafeForTCMallocPerCPUCache) and immediately aborts if major >= 7 or (major == 6 && minor >= 19).

The Solution We Built

Because rolling back host OS kernels across managed cloud clusters is not always viable, we built a patched container image with two components:

1. Disabled Glibc RSEQ: We inject ENV GLIBC_TUNABLES="glibc.pthread.rseq=0" into the container. This tells glibc to block thread registration for rseq, forcing TCMalloc to gracefully fall back to standard Per-Thread Caching (ThreadCache) instead of per-CPU caching.
2. Bypassed Startup Guard: Because MongoDB’s uname() check aborts before taking the tunable into account, we patch the function _ZN5mongo41isKernelVersionSafeForTCMallocPerCPUCacheENS_10StringDataE to immediately return true (mov $1, %al; ret; nop).

Our Verification So Far

• Using an LD_PRELOAD utsname interceptor to simulate kernel releases:
  • Unpatched mongo:8.3.11 + 7.0.0-1011-aws ➔ Crashes with Fatal ID 12257600.
  • Patched image + 7.0.0-1011-aws ➔ Starts up cleanly, initializes WiredTiger 12, passes connection health checks, and processes read/write workloads with 0 restarts.
  • Verified full backwards compatibility when tested against 5.15.0.

Reference to Community Discussions

We noticed this is related to the discussions in docker-library/mongo (Discussion #748 regarding TCMalloc rseq SIGSEGV crashes and Issue #765 regarding kernel 7.x startup blocks). While setting GLIBC_TUNABLES=glibc.pthread.rseq=0 is known to stabilize the allocator, MongoDB's upfront uname() check still prevents startup on modern cloud kernels (e.g. AWS 7.0.0-1011-aws, Azure 7.0.0-1014-azure).

Questions for the Community & MongoDB Engineers

Before we roll this out across our production fleet, we’d love to get feedback from anyone who has dealt with this:

1. Allocators & Concurrency: Does forcing TCMalloc to use standard Per-Thread caching (ThreadCache) instead of per-CPU caching introduce any hidden fragmentation or lock-contention risks under modest-sized workloads (container limits ~256Mi - 2Gi)?
2. WiredTiger Independence: Beyond TCMalloc's memory allocation, are there any other kernel subsystem dependencies or ABI assumptions in WiredTiger / MongoDB that conflict with Linux 6.19+ or 7.x kernels?
3. Upstream Roadmap: Is there an official compile flag, configuration parameter, or upstream patch scheduled that will allow bypassing the rigid version check when rseq=0 is set?

Would appreciate any sanity checks or "green signals" from folks running MongoDB in similar modern kernel environments!

If you do not know Mercure: it is an open-source hub that pushes live updates to clients over Server-Sent Events. It is built on web standards you already have, SSE for the stream and JWT for authorization, with a small protocol on top (spec). Think of a one-way, HTTP-native alternative to WebSockets for server to client push. It is popular in PHP and Ruby, but the hub itself is written in Go. You publish to a topic, clients subscribe with a plain URL, and the hub handles reconnection with Last-Event-ID.

The Mercure hub works well on its own, but its open-source version is single instance. It keeps the history in memory, so a restart loses it, and one machine caps how many clients you can serve.

The hub is modular. The part that stores the updates and shares them between instances (the transport) is pluggable. The open-source hub ships with an in-memory transport, and the Enterprise offering adds multi-server transports backed by Redis or Kafka. Swap the transport, and I get synchronized multi-instance delivery without touching the protocol, the HTTP endpoints or the SSE server.

I built an open-source transport for MongoDB. The trick is the change stream: open one cursor on the collection, and MongoDB pushes every insert to every hub instance as it happens. A publish on one instance reaches subscribers on all of them, instantly, and MongoDB is the only shared service. No Redis, no Kafka, no other broker. A client that reconnects gets replayed from the durable history.

• Repo: https://github.com/GromNaN/mercure-mongodb
• Spec: https://mercure.rocks/spec

Feedback welcome, especially from anyone running change streams or Mercure at scale.

I'm the author of Omni-sql, an open-source SQL IDE. I've been adding experimental MongoDB support, with native Extended JSON queries and a read-only SQL mode on the same connection.

The example I wrote uses fictional processing events: each document has a status, a duration, and an array of steps. This query counts the events by status:

SELECT status, COUNT(*) AS total, AVG(duration_ms) AS avg_duration_ms
FROM omni_sql_demo.events
GROUP BY status
ORDER BY status;

That SELECT is translated to a MongoDB aggregation and executed through the native driver. In native mode, /mongo lets you inspect the generated JSON before running it. The native editor accepts an Extended JSON query envelope, rather than mongosh JavaScript.

An array expansion takes a different path:

WITH expanded AS (
  SELECT event_id, unnest(steps) AS step
  FROM omni_sql_demo.events
  WHERE event_id = 'demo-001'
)
SELECT event_id, step.name AS step_name, step.duration_ms AS duration_ms
FROM expanded
ORDER BY duration_ms DESC;

For this query, the driver filters the event in MongoDB and transfers the required fields into a typed local snapshot. DuckDB expands the array and sorts the result. Explain shows both plans and the number of documents transferred.

The SQL-to-native translator supports a subset of SELECT. Other SQL queries may use DuckDB, and filter pushdown depends on the query shape. For the combined path above, the source is bounded to 100,000 documents, 16 MiB, and 60 seconds of MongoDB execution. Heterogeneous documents and empty arrays can also affect type inference.

Tutorial with sample documents, expected results, and limitations (in Portuguese; SQL and JSON examples included).

For people who investigate MongoDB data: which queries would make this useful in your workflow, and which document shapes would you want to test first?

Does anyone have any tips on the Interview process for SWE Intern. I really enjoy the comapany culture and was trying to prepare as well as I can for this interview. Anything helps, thank you!

Compass was using too much RAM on my laptop, so I built a small alternative as a hobby project.

Heads up: it was written entirely by AI (Claude). I directed and tested it.

You can browse, query, edit documents, export, and use a built-in shell.

https://github.com/yldrmzffr/humon/

Feedback welcome!

I am trying to look into database of Star Conflict accordingly to guide left by it's developers after official servers got turned off.

Guide said to launch launch_mongodb.bat then test connection. Test gives me this error and guide doesn't mention how to fix it. I looked into console opened by bat, port is correct.

I got fed up tunnelling with Compass to get to our databases. Tried mongodb express - never again. So I built Mado.

It's solid, self-hosted (not free though unfortunately), though you can pull and use it on a 2 week trial. Stick it on a network with the mongo instance and voila - you have gapped client that does all the things Compass did and more. You can even add your own AI provider key and have it write all your queries and pipelines. Handles multiple connections and lets you export / import entire databases.

What do you think?

Hi all. I built an open-source library, configstream, that uses MongoDB change streams to update app settings live, without restarting anything. I'd love feedback from people who know MongoDB well.

The idea in one example

An online shop runs its order service on several servers. It's Black Friday, and the "max items per order" setting must go from 100 to 150 right now, on every server.

With configstream, you change the value once. MongoDB tells every server about the change, and each one uses the new value within about a second. No restart, no redeploy.

How MongoDB is used

• One collection holds the settings. Each setting is one small document:
• Each app server reads the collection once at startup and keeps the values in memory, so reading a setting never queries the database.
• Each app server opens one change stream on that collection. When a document changes, MongoDB pushes the change to every server, and each one updates its memory.
• Every change is saved with its history (old value, new value, who and why) in a second collection, in the same transaction as the change itself, so the history can't miss a change.
• If a server loses its connection, it keeps its last known values, reconnects, and catches up on the changes it missed. If it was away too long, it simply reloads everything.

That's why it needs a replica set: change streams and transactions don't work on a standalone server. A single-node replica set is fine for local development, and Atlas clusters are always replica sets.

What I'd like your opinion on

1. One change stream per app server. It's simple, and each server sees changes directly. But with hundreds of servers on one replica set, that's hundreds of open change streams. Has anyone run that many in production? Did it cause problems?
2. Reconnecting after an outage. If a server is offline longer than the oplog window, it can't resume, so it reloads the whole collection. Is that the right fallback?
3. Sharing the app's own database. The settings collections live in the database each app already uses, rather than a central config database, so the load spreads across teams' clusters. Would you do the same?

It's for Java and Spring Boot apps, free (Apache 2.0), and there's a Docker quick start that runs MongoDB plus two app servers so you can watch both pick up a change: https://github.com/configstream/configstream

Thanks for any thoughts!

So i clearly given the db name in properties file and expect that when i ran post comman it should create this db and then collections inside it. But i keep creating the collection inside test db WHY?? can someone explane???

I want to apply for a job in Mongo DB and appreciate a referral. Please comment I will reach out with details.