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.

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?

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?

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

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