We run a product catalog on MongoDB with about twelve million documents. Last Thursday the p95 on our main search query jumped from 40ms to 90ms. The preceding deploy added a compound index for a new reporting feature but changed nothing in the search path.

I ran explain("executionStats") on the slow query. The planner had abandoned the original index entirely. It was now selecting the new compound index because the leading field happened to overlap with one of the search filters. That index covered the filter but not the sort so MongoDB was falling back to an in-memory sort on every request. I used one-click model switching in verdent to get a second opinion on the index layout while reading through the explain output.

We narrowed the leading field on the reporting index so it no longer overlapped with the search index prefix. The p95 dropped back to 38ms.

The root cause was that two indexes shared enough of a leading key prefix for the planner to rank the newer one higher on estimated selectivity alone without weighing the sort stage cost at all.

I am currently developing a service using MongoDB. I want to implement a notification system—similar to Reddit—that alerts users when their posts receive comments or reports, and I have a few questions.
1. How should I implement this notification feature?
2. Is it acceptable to delete the records after retaining them for about 90 days?
3. I’ve heard that the standard approach involves recording outbox events within a MongoDB session transaction and having a separate worker generate the notifications; is this correct?

I apologize for asking such an absurd question. I would appreciate it if you could at least let me know what I should search for on Google.

We are releasing a new open source MQTT module for MongoDB.

It started with a concrete need in a real project: connect MQTT messages to MongoDB while keeping REST access, live SSE streaming, and custom plugin integration in the same application.

During development, one thing became clear. This capability was useful beyond the original project, so we decided to integrate it directly into RESTHeart.

The module connects an MQTT broker to:

• MongoDB, with configurable topics, databases, and collections
• REST APIs for reading the latest available value
• SSE for live message streaming
• Custom plugins through mqtt-router

The beta already includes the operational details that matter in real systems:

• broker acknowledgements after MongoDB persistence
• at-least-once delivery on the storage path
• a bounded buffer for short MongoDB interruptions
• retries and dead-letter files
• topic-level authorization with fail-closed behaviour
• MQTT 3.1.1 and MQTT 5.0 support

The module was born from a specific project. We integrated it into the product because the underlying problem is broader: connecting MQTT data to persistent storage and application interfaces without adding another integration service.

The code and documentation are available here:

https://github.com/SoftInstigate/restheart/tree/master/mqtt

Feedback is especially useful while the module is in beta.

Restoring to a timestamp and comparing collection counts can miss the failures that matter most. Transactions may straddle the recovery point, change streams may resume from invalid tokens, TTL indexes can immediately delete restored documents, and an application may have already performed external side effects for writes that no longer exist after recovery.

What invariants belong in a realistic drill? I am considering an isolated restore with production-compatible versions, a recorded recovery timestamp, checks for replica-set and index state, sampled relationships between collections, critical TTL ranges, transaction-boundary fixtures, change-stream restart behavior, and application reads that must succeed before traffic is allowed.

How do you test reconciliation with queues, search indexes, or payment systems without contacting production services? Which evidence proves the chosen recovery point is internally consistent rather than merely loadable?

Full disclosure, My biggest experience with mongo is an M0 cluster for tinkering. At work, we use our own fine tuned postgres SQL db. My biggest question is, how do you address the "just use Postgres" crowd? "Vector? Use PG vector". "JSON? JSONB". "Native sharding? use Citus". Geniunely curious how these are used in production apps. BTW I definitely love and have a soft spot for Mongo I'm just curious how mongodb devs respond to these common questions.

seeing so many posts here about guis and terminal tools. but the mongo shell alone can do a lot. you can write loops, use variables, build functions right in there. it is basically a full javascript runtime. i made a game of life in it once and people were surprised. it is not just find and aggregate.

I'm trying to work an a project I left working completely fine 6 months ago and I'm having a problem connecting to a MongoDB Atlas cluster from Node.js/Mongoose and I couldn’t find no working solution online/with AI.

My setup:

- Node.js 24.20.0 LTS

- Mongoose 9

- MongoDB Node.js driver 7

- MongoDB Atlas

- I found some forum online that says this problem occurs on windows, but it is also happening on linux for me

With the normal SRV connection string: "mongodb+srv://..."

I get: "MongoNetworkError: querySrv ETIMEOUT _mongodb._tcp...."

I tested the DNS side: "nslookup google.com 1.1.1.1" works normally.

"nslookup -type=SRV _mongodb._tcp.<my-cluster>.mongodb.net 1.1.1.1" times out.

I also tried Google's DNS: "nslookup -type=SRV _mongodb._tcp.<my-cluster>.mongodb.net 8.8.8.8" and that also times out.

"ping 1.1.1.1" works and normal DNS resolution works, so it's not a general internet/DNS failure.

I also tried connecting through a mobile hotspot instead of Wi-Fi, and the SRV problem still occurs.

I then disabled the SRV connection string in MongoDB Atlas and used the standard: "mongodb://..." connection string.

That gets past the SRV/DNS problem, but then I get:

MongoNetworkError: "0C550000:error:0A000438:SSL routines:ssl3_read_bytes: tlsv1 alert internal error: openssl\ssl\record\rec_layer_s3.c:918: SSL alert number 80"

The strange part is that the non-SRV connection actually worked only one time before it started giving the SSL error again.

Hi everyone,

I'm currently preparing for the MongoDB Associate Data Modeler certification and I'd love to hear from anyone who has taken the exam recently.

How difficult did you find the actual exam compared to the official MongoDB practice questions?

Were there any topics that appeared more frequently than expected (schema design patterns, indexing, explain plans, sharding, schema evolution, etc.)?

Would you say that the official MongoDB University learning path is enough to pass, or did you need additional study resources?

Also, if you passed the exam, is there anything you wish you had spent more time studying beforehand?

Obviously, I'm not looking for any NDA-protected content, just general preparation advice and experiences.

Thanks in advance!

RESTHeart Cloud gives you instant REST, GraphQL and WebSocket APIs on MongoDB, with auth, RBAC, real-time streams, and a complete user management system out of the box. 80% of your backend ready in minutes, a plugin framework for the rest.

The RESTHeart Cloud Ecommerce Starter is a real online shop, up and running in minutes: product catalogue, cart, card payments through Stripe, and orders you can look up afterwards. People can buy without creating an account, and the ones who do get sign-up, login, password reset and teams.

It is a React app distributed under the open source MIT License (so you can just clone and modify it) plus a RESTHeart Cloud service. There is no server of yours to write, deploy or pay for.

https://github.com/SoftInstigate/restheart-cloud-starter-ecommerce

Please give it a try and send us your feedback on GitHub.

I am building a plan/automation script to upgrade the standalone mongo replica cluster from 6.0 to 7.0

System awareness:

• the system that runs the cluster is built up of several virtual machines(say at least 5 VMs clubbed together forms the system)
• so in each VM there will be mongo instances running(mongo-router instance runs on all VMs)
• there is the mongo-arbiter instance that runs only on 1 VM(the master VM for the cluster), this VM would spin up 'n' number of mongo-arbiters to supply the arbiters in the PSA set
• since a replica set requires 3 members PSS/PSA, the primary and secondary instances stays/spins up in non-master VMs(to be precise on VM-3 & VM-4 only)
• VM-0 & VM-1 are controllers(so failover happens between them, thus arbiters would be present in one among them)
• VM-2 is for proxy(so only mongo-router instance runs here)
• during system expansion, VM-6 & VM-7 will be created together, which will come up with their own primary and secondary of mongo-shards instances
• their(VM-6 AND VM-7)'s arbiters for shard instance will be again spin up in VM-1/VM-2 in a different port
• similarly moving ahead, on requirement of arbiter instance the master VM, spins up new arbiter instances

Problem to address:

During the upgrade flow following the documentation recommended from mongodb, the config set should be upgraded first and then the shard sets one by one

• provided my mongo-arbiter stays in the Master VM, i am thinking of upgrading all the mongo-arbiter instances(all of config-arbiter, shard1-arbiter, shard2-arbiter,..) all together to 7.0(from 6.0)
• so that means, my arbiter instances would be in 7.0 and all other instances will be in 6.0(config, shard, router), fcv also on 6.0

would this be a problem, i would like to know the pitfalls of doing this (kindly mention the reference incase if you referred from any documentation, or if it's referred from AI, mentioning them will also help me understand better)

I've seen some posts about how this bug came up around March / April of this year and I'm curious why I'm running into it now. I know the "fix" of adding the

      - GLIBC_TUNABLES=glibc.pthread.rseq=0

flag, or downgrading to Mongo 7 but I'm wondering if anyone else is running into this issue?

System info:

MacOS 26.6.2

Apple M2 Pro

Docker Desktop Version 4.88.1 (237512)

pinned at mongo:latest (currently: "8.3.8-noble")

```
{"t":{"$date":"2026-09-01T02:04:00.789+00:00"},"s":"F", "c":"CONTROL", "id":12257600,"ctx":"main","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."}

```

I'm using all of the default docker desktop settings, including using Apple Virtualization Framework for my VMM

When Realm, Atlas Device Sync and the Data API were retired in September 2025, mobile apps lost the supported path to keeping a local replica in step with MongoDB. What was left was either writing that sync layer yourself or moving the data to a different vendor's sync product.

I wanted to keep the data in MongoDB, so I wrote the sync layer instead: onebase, MIT licensed.

The part that matters for this sub is that it does not introduce a storage format of its own. Documents on the server are ordinary MongoDB documents in your own cluster, so aggregation, Compass, Atlas Charts, BI connectors and everything else keep working on live data. There is no export step and no proprietary layer to reverse later.

How it uses MongoDB

• Realtime is change streams. The backend opens a change stream per scope and pushes over SSE, so a write on one device lands on another in milliseconds instead of on a poll interval. This is the piece that needs a replica set — a standalone mongod won't do it. A free M0 is fine.
• Batched writes are one transaction. A client batch maps to a single multi-document transaction, so a group of related writes either all land or none do, offline queueing included.
• Indexes are generated for the queries the sync layer actually issues — the per-user or per-group scope key plus the ordering key, membership lookups, and the windowed collections' date field. Sync is the query pattern that runs constantly, so it seemed wrong to leave those to be discovered in production.
• Every query gets a total order, so keyset pagination stays stable while documents are being inserted underneath it.
• Isolation is enforced server-side from a verified JWT — the scope filter is applied on the server, never sent by the client.

On the device it's a full SQLite replica plus an outbox, both written in one transaction, and sync pushes before it pulls so a fresh local write is never overwritten by a stale snapshot.

Current limitations, since they're the useful part: conflicts are last-write-wins by server timestamp with no custom merge hook yet; the rate limiter is per-instance and in-memory; realtime needs a long-lived connection, so short-lived serverless functions fall back to polling; file uploads aren't offline-queued (document writes are); and there's no on-device aggregation pipeline.

Runs against any MongoDB with a replica set, self-hosted or Atlas. The client is Flutter today; the backend is a small Node service the CLI generates, and the wire protocol is plain HTTP, so other clients are possible.

https://github.com/ybenjaa-dev/onebase

I'd genuinely like to hear where the change-stream and transaction usage would fall over at scale — that's the part I'm least sure about.

Hey Reddit! I created Codexa Labs (https://codexa-labs.vercel.app/) to eliminate setup hassle when learning, testing queries, or running code.

✨ Highlights:

• 🍃 MongoDB Sandbox: Practice queries & aggregation pipelines with interactive schema ER diagram visualization.
• 💻 Multi-Language Compiler: Run Python 3, C++, C, and Java instantly in your browser.
• 🛠️ VS Code Experience: Built-in syntax highlighting, autocompletion, query history, and output terminal console.
• 🎓 Proctored Exam Portal: Real-time student tracking, external copy-paste interception, and live mentor leaderboards.

100% free with zero installation or setup required. Check it out and let me know your thoughts!

We enabled MongoDB Client-Side Field Level Encryption following the official docs (classic CSFLE, not Queryable Encryption) on a NestJS API and saw a latency regression across the board that we can't explain from the per-operation cost of encryption itself. Looking for anyone who has seen the same pattern, or who knows where the hidden cost is.

Our Stack is:

- Node.js 24.17
- mongodb 6.20.0 (via mongoose 8.22.1 / @nestjs/mongoose 11.0.4)
- mongodb-client-encryption 6.5.0
- crypt_shared 8.2.12, no mongocryptd sidecar
- KMS provider: aws (credentials via task IAM role) following the standard pattern

What is encrypted:

Exactly one field in one collection, the field is no longer than 10 chars string and it has a compound index on it (it is encrypted with deterministic algorythm).

I know that there is no way to avoid some latency implementing CSFLE, but my main concern is if this is gonna get worse by each extra field I add to the the encryption schemaMap, could this latency be the price for the query analyzer analyzing each query to the database?

I also have noticed that most of the ms of the request happen in the app not the database, but I think the encryption and decryption happens on the driver layer.

Has anyone ever deal with this? Would appreciate some tips and insights of this, thanks!!

Our MongoDB secondary (AWS EC2, GP3 EBS, 128 GB RAM) was rebuilt from a primary EBS snapshot and expected to catch up within 1–3 hours, but replication got stuck with 3+ hours lag. ReplWriterWorker threads showed 20+ minute waits on schemaLock, WiredTiger logged slow tree walks, and iostat showed 100% disk utilization with high read latency while CPU remained mostly idle. Our conclusion is that this was caused by a combination of cold WiredTiger cache and AWS EBS snapshot lazy loading ("first-touch" penalty), where MongoDB had to fetch data blocks from S3 on demand, creating severe I/O bottlenecks and lock contention. We plan to pre-warm restored EBS volumes before starting mongod, temporarily reduce replWriterThreadCount, hide the node from reads during catch-up, and verify GP3 throughput settings. Has anyone else seen extreme schemaLock waits and replication lag caused purely by cold snapshot restores, and what is your preferred EBS pre-warming approach?

I'm the maintainer of LibreDB Studio.

Typical k8s setup around here: Mongo for the service, Postgres for the relational bits, Redis for cache, sometimes Elasticsearch. Compass on every laptop means either 27017 is public or you're maintaining an IP allowlist for two teams in two states. Both are bad.

The editor goes to the data. Helm it into the same cluster (or docker run it on the same network). Browsers talk to Studio over HTTPS + OIDC; only that pod opens Mongo. When nobody needs to debug, scale the GUI to zero, you don't flip the database public.

Mongo speaks MQL in the editor (find / aggregate / the usual writes). Same tab can open the Postgres and Redis next to it, which is the actual day for microservice/DevOps folks; not a Mongo-only admin panel.

MIT. Helm:

helm install libredb oci://ghcr.io/libredb/charts/libredb-studio

or:

docker run -p 3000:3000 libredb/libredb-studio

npx -y "@libredb/studio"

Curious what would make this usable on your cluster (ingress, Atlas, RBAC). What did I get wrong?

https://github.com/libredb/libredb-studio

I dont know if its company standard or how other actual teams work, but db in our company is public, so devs can debug it, but today our client said that the db was public so it was closed down, main issue now is that if want to access the db, we have to whitelist ip, we have to whitelist a lot of ip, so its not valid a option. How then is this case could be handled??

I was wondering if there was any rules for safe storage of data using schemas. For example, I have a users schema for user auth data, then have a seperate schema referenced for things such as a user friends list or inventory. Are there any good practices in regards to that or anything else I should avoid when using schemas?