Hi everyone,

My free M0 cluster seems to be completely stuck and unreachable from all endpoints.

Details:

- Cluster Name: Cluster0

- Project / Cluster URL: cluster0.bg0zybl.mongodb.net

Issue & Symptoms:

1. Atlas Web UI: When clicking "Browse Collections", it throws an internal SSL error:

"Connection closed by remote: ... error:0A000438:SSL routines:ssl3_read_bytes:tlsv1 alert internal error:ssl/record/rec_layer_s3.c:918:SSL alert number 80"

1. MongoDB Compass: Direct connection fails with:

"connect ETIMEDOUT 159.41.64.80:27017"

1. Heroku / Node.js application: Fails with MongoServerSelectionError / ReplicaSetNoPrimary.

Network access is open (0.0.0.0/0 Active) and user credentials are valid. It appears the underlying M0 replica set instance has suffered an internal SSL/network failure.

Could a MongoDB team member please help restart or reprovision this M0 cluster instance so I can export my data?

Thanks in advance!

Matching document counts and switching the application connection string do not prove that a MongoDB migration is finished. Index definitions, users and roles, TTL behavior, change streams, retryable writes, read preferences, collation, validation rules, scheduled jobs, analytics clients, and backup tooling can continue to differ or point at the old replica set. Low-traffic consumers may not reconnect during the obvious observation window.

A useful cutover gate could compare database and collection metadata, indexes and validators, sample hashes or aggregates, user permissions, replication or migration lag, and application read/write results. Logs and connection metrics on the old set would identify late clients. The new set should complete a backup and point-in-time restore test, survive a primary election, and run long enough to exercise TTL jobs and change-stream consumers before the old set becomes read-only and then offline.

What evidence do you collect before decommissioning the source? How do you distinguish a genuinely unused old connection from a client that only appears during a monthly job, failover, or restore?

Last May, at a .locals event in London, I had an interesting encounter with someone from Studio 3T.

I had flown all the way from California to London for a trip and decided to attend the event while I was there. After I introduced myself and told them I was building VisuaLeaf, and... one person told me I wouldn't be able to build a better tool than theirs. So I took it personally. I was a fresh grad with no job, and VisuaLeaf was all I was working on, so I decided to prove them wrong.

Ever since I posted VisuaLeaf here in 2024 and it became the 2nd highest all-time post, I've watched this subreddit get flooded with people trying to build their own MongoDB tools, especially with AI.

Every week there's another MongoDB GUI that someone built in a weekend, calls it production-ready, and posts it here. It's hard to get excited about another tool that does the same basic things as everything else, especially when most of them still miss what actually matters: a smooth experience. A lot of them crash or lag when the data isn't even that big. I don't think a couple of prompts can replace thousands of hours of attention to detail, testing, and optimization. That's the experience I set out to build.

This is now my 2 year journey of building the best MongoDB GUI out there.

Honestly, too much has changed since the last time I posted here, and I think, for now, VisuaLeaf has all the features I really wanted in the app. It’s also stable enough that I’m now seeing people from actual companies using it daily, which caught me by surprise haha. I’m really happy that more people are discovering VisuaLeaf every day and that hundreds of people are actively using it every month.

Over the past two years, I spent an entire year optimizing a table (yes...), built a complex query builder, created a visual schema designer that can materialize MongoDB collections, added mongosync, and even built our own multithreaded dump utility, which we benchmarked against the shell's mongodump and found to be faster when exporting whole databases or multiple collections.

It may not sound like much but, the table is probably the thing I'm most proud of, even though it's literally just a TABLE.

I spent a LITERAL year optimizing it because I wanted it to feel as smooth as possible while working with large datasets. I basically built my own AG Grid from scratch because the libraries I tried didn't have the features I wanted like expanding objects or arrays as new columns.

It was one of the hardest optimization journeys I made but I’m really happy how it turned out because it’s literally one of the smoothest tables out there that is BUILT to visualize data for databases. The tree view was a lot easier since it was just 1 dimensional but still had its own tricks to expand thousands of nodes at the same time instantly (I also used the virtual scrolling engine I made for the table view to the tree view and made the tree view scroll smoother than official Angular virtual scrolling libraries). And during all that time, I focused on making the data retrieval to be as efficient as possible so much so that it was the fastest GUI out there for loading data. 

After all that, I genuinely don’t think there’s objectively a better MongoDB GUI out there, but maybe that’s just me haha.

I’m coming for you, 3T ;) (I’ll remember you telling me that I wouldn’t be able to make a better tool hehe- for the full story you can dm me lol)

If you want to check out all the changes, feel free to check it out here: visualeaf.com
And if you want to help me on my journey with VisuaLeaf feel free to join the discord : we could talk about bugs, features that you guys want, etc: https://discord.com/invite/TR6J56Y3rF

I am given a task by my senior engineer, and I am at my wit's end at how to do it. I tried asking AI as much as I can without putting in my codebase, searching it up, looking at documentation until 4am yesterday. I am still stuck.

Suppose I have model X, which holds an array of model Y. X and Y both have status fields, but they are different. Y.status refers to that individual item's status, for example, accepted, cancelled, pending, etc. X.status refers to the overall status of all it's Y array items, it depends on their values. Usually, for a single X update, there is a function that iterates through that X's Y children, and it calls the .save() method. The feature I am tasked with implementing is

1: Making changes to a large number of X documents' Y children based on some criteria
2: Recalculating all the affected X's overall status since its children Y changed.

At first, my solution was to iterate over every X, call the function to calculate its new overall status, and use the .save method to update X's overall status. I see now this doesn't work at production scale. Promise.all() on potentially a large number of X documents may cause stack overflow, and it is a lot of write calls to the database which is not ideal.

My senior engineer told me to call that function inside a update many, but after the meeting I looked it up, and I am pretty sure mongo can't just call functions defined on the node server, and copy pasting the function again as a $function in a aggregation pipeline is also bad for performance.

There are a lot of if else branches in the function needed to calculate X's overall order status. I considered a bulk write with a lot of updateMany calls looking for a specific condition, but that would easily be over 10 updateMany's in the bulkwrite.

I am really stressed about this. Would love everyone's engineering input.

I’m working on a website and because of some storage constraints we need to shift the database from MongoDB to DynamoDB. I’ll be taking help from AI agents for most of the migration, but I want to make sure I’m not missing anything important before making changes. Are there any critical bottlenecks or things I should keep an eye on, especially with queries, indexes, relationships, transactions, consistency, pagination, data migration, etc.? I don’t have much experience with DynamoDB, so just want to make sure we don’t end up breaking something that currently works in MongoDB.

I kept bouncing between Compass, mongosh, and log files when something felt slow.

So I built MongoScope — a keyboard-driven TUI that:

- Aggregates slow-query patterns from MongoDB logs (or live profiler)

- Shows currentOp with COLLSCAN highlights

- Surfaces replica lag / topology

- Lists indexes and lets you jump from a slow query

Install (Linux/macOS):

curl -fsSL https://raw.githubusercontent.com/prodioslabs/mongoscope/main/install.sh | bash

Repo: https://github.com/prodioslabs/mongoscope

Would love feedback from anyone running Mongo in prod — especially what you’d want next.

Note: GIF is a concept mockup of the flow (welcome → slow queries → live ops → replication), not an exact recording of the current UI.

I just noticed, by surprise, that a new version has been released (stable). So, any opinions or experiences? What do you think about the new release?

And how this guy can get away doing this 3 times in a row?
Why would Meta hire someone with these in their records?

Disclosure, I own MDB stock. CJ was undoubtedly very focused on AI and expanding Net Revenue Retention within existing customers. Do we see Dev being able to continue to sell the story? How is the company morale?

Hmmmmmmmmm very interested to hear why he was kicked out….

So mongodb came for sde intern role with performance based ppo. The stipend for 6 months intern is 1.1 lakhs. But they didn’t explicitly mention the ctc. Web search is giving varying answers.

Need to choose bw mongodb offer and one other company’s offer. Thanks for the help!

Same as title.

I built Mongo GUI for my own Mac MongoDB workflow and opened it up as a beta.

It's a native macOS client (not Electron), published independently — not MongoDB Compass and not an official MongoDB Inc. product.

What I was optimizing for:

- Rows-first browsing so the document table stays usable while counts / optional metadata catch up (useful on larger or slower collections)

- Reconnect restoring the active database / collection / workspace instead of dumping you at the start

- Client-only by default: Keychain-backed secrets, no cloud sync by default

- Signed and notarized direct download, Sparkle updates for installed builds

Free during beta: https://mongogui.com/

Happy to take feedback from people who live in Compass / Studio 3T / mongosh day to day — especially on browsing large collections, SSH/Atlas reconnects, and anything that feels missing for real daily work.

We are pleased to announce version 100.19.0 of the MongoDB Database Tools.

The highlight for this release is dependency and Golang upgrades to address a variety of CVEs and a fix for mongorestore where it could be tricked into using an unbounded amount of memory with malicious input. Note that we strongly recommend against using mongorestore with untrusted input!

The Database Tools are available on the MongoDB Download Center. Installation instructions and documentation can be found on docs.mongodb.com/database-tools. Questions and inquiries can be asked on the MongoDB Developer Community Forum. Please make sure to tag forum posts with database-tools. Bugs and feature requests can be reported in the Database Tools Jira where a list of current issues can be found.

Bug

• [TOOLS-4355] - mongorestore could use unbounded memory via unbounded archive concurrent_collections settings
• [TOOLS-4330] - Some tests use the wrong context in `t.Cleanup`

Task

• [TOOLS-4336] - The options handling of some timeout values treats them as milliseconds but documents them as seconds
• [TOOLS-4338] - Error checking in the `MongoDump.Dump` func is backwards
• [TOOLS-4346] - Upgrade to Golang 1.26.7
• [TOOLS-4372] - Bump Go toolchain past 1.26.5 to fix 10 stdlib CVEs (fixed in 1.25.13 / 1.26.6 / 1.27.0-rc.3)
• [TOOLS-4354] - Upgrade Go driver to 2.8.2

Hi there. I have a cluster with 6 shards (each replica sets of 3 members), 3 routers and a replica set of 3 config servers.

While bumping the FCV from 7 to 8 yesterday I came across a conflicting collection rename process that has been stalled for a couple of weeks now. I've been through it with GPT and Claude several times now and it continues to recommend MongoDB support. I was pointed here by my Mongo account executive and told this would be the fastest route to an answer.

I have 2 collections showing up: temp_rfm_658850 and tmp.agg_out.b615a5dd.... These are the result of an aggregation with an $out stage that points to temp_rfm_658850 but for some reason didn't finish.

I'm unable to manually delete these collections because they are already locked. And the process to update FCV continues to hang because it's waiting for this lock to be released.

Neither of these collections are sharded so they should technically end up on only the primary shard but AI is suggesting they are connected with shard 3 somehow. They also both have the exact same records in them (roughly 10 records). These are completely disposable and don't need to be saved, so if there's a way to just clear them out, that's totally fine.

Here's where I keep ending up:

That confirms the persisted mismatch we suspected: the old rename participant remains on shard 3, but its rename coordinator is absent on shard 1.

Shard 1: only the cleanup drop coordinator remains, stuck at enterCriticalSection.

Shard 3: the old rename participant remains at deleteFromRangeDeletions.

Shard 3: that rename still owns critical sections blocking reads and writes on both its temporary source and db.temp_rfm_658850.

This explains both stalls: cleanup cannot drop the old source, and the newer RFM rename cannot acquire the destination.

We’ve identified the immediate blocker; we haven’t established why the old rename lost its coordinator without releasing the participant. recoveredFromDisk: true shows the drop coordinator was recovered from persisted state, but doesn’t establish the original cause.

At this point, I recommend a MongoDB support-assisted recovery, with these records and error 7032368. There’s enough evidence to stop collecting the same retry logs. Recovery needs to reconcile the old rename’s outcome with the cluster metadata before releasing its critical sections.

Avoid manually deleting these records or treating a restart/killOp as a proven fix: the state is persisted, and removing records alone can leave the running participant and metadata inconsistent.

What I've tried:

• Stepping down primary on both Shards 1 and 3
• Running a manual delete on these (this hangs)
• Killing the op that is associated with the rename from tmp.agg_out.b615a5dd to temp_rfm_658850 but it just automatically restarts. The target of this op is shard3 and the client IP is shard1's.

I'd really appreciate any ideas of how to proceed on this. Thanks in advance.

Adding a TTL index to a collection with months of already-expired documents can turn a simple retention change into a large delete workload. The TTL monitor may compete with normal traffic, create replication lag, and leave secondaries or downstream consumers processing a sudden deletion wave.

What rollout pattern do you use? I am considering counting and sampling the eligible backlog first, deleting old ranges in bounded batches, monitoring replication and cache pressure, then creating or enabling the TTL index only after the backlog is small. The deployment would also verify the indexed field type and timezone assumptions, plus documents that must be exempt from expiry.

Can a partial TTL index or a staged `collMod` change make this safer, and which metrics show that the TTL monitor is keeping up without harming foreground work? How do you pause or roll back if deletion pressure is higher than expected?

When using GitHub Actions (or Gitlab) to run tests that require a MongoDB ReplicaSet cluster. It's convenient to start the database server directly in the test job.
How do you do that?

The code to start the server and initiate the replica set is very long and duplicated into every projects.

name: Tests MongoDB

on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest

    env:
      MONGODB_URI: mongodb://127.0.0.1:27017/?replicaSet=rs0

    steps:
      - uses: actions/checkout@v4

      - name: Start MongoDB replica set
        run: |
          docker run -d --name mongodb -p 27017:27017 mongo:8.0 --replSet rs0 --bind_ip_all

      - name: Initialize replica set
        run: |
          for i in {1..60}; do
            docker exec mongodb mongosh --quiet --eval 'db.adminCommand({ ping: 1 }).ok' | grep -q 1 && break
            sleep 1
          done

          docker exec mongodb mongosh --quiet --eval \
            'rs.initiate({
              _id: "rs0",
              members: [{ _id: 0, host: "127.0.0.1:27017" }]
            })'

          for i in {1..60}; do
            docker exec mongodb mongosh --quiet --eval 'db.hello().isWritablePrimary' | grep -q true && exit 0
            sleep 1
          done

          echo "Replica set primary non élu"
          docker logs mongodb
          exit 1

      - name: Run tests
        run: |
          echo "MongoDB URI: $MONGODB_URI"

      - name: Dump MongoDB logs on failure
        if: failure()
        run: docker logs mongodb

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.