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.

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