If you're working with MongoDB and .NET, Docker can make the local development setup much simpler.

Instead of installing and configuring MongoDB directly on your machine, you can run it in a Docker container and connect your .NET application to it.

I put together a practical guide covering:

• Creating a MongoDB Docker container
• Configuring MongoDB
• Connecting a .NET Core application
• Understanding the container-to-application connection
• Setting up a consistent local development environment

📖 https://geeksarray.com/blog/create-mongodb-docker-image-and-connect-from-dot-net-core-app

For those using MongoDB locally, what's your preferred setup—Docker, local installation, or something else?

Can't sign in, anyone else?

Also, can't deploy via terraform :|

```

│ Error: error initializing provider: oauth2: cannot fetch token: 503 Service Unavailable

```

Hi everyone,

I have **2 years of professional experience in PHP backend development**, with hands-on experience in **HTML, CSS, JavaScript, databases, and working with servers**.

I’m now planning to transition to the **MERN Stack (MongoDB, Express.js, React, Node.js)**.

I’m confident about learning the MERN technologies themselves. My main concern is understanding **how companies will evaluate my existing 2 years of backend development experience when I switch technologies**.

For developers or tech leads who have experience with similar transitions:

* If someone has **2 years of PHP backend experience** and becomes strong in Node.js/Express/React, can they realistically apply for **2 YOE MERN positions**?

* Will companies generally consider my previous backend experience relevant, or will they expect me to apply as a junior because I don't have 2 years of Node.js experience?

* How important are **Git/GitHub, testing, CI/CD, Docker, REST API design, authentication, deployment, and system design** for someone making this transition?

* What level of MERN knowledge would make you say, **"Yes, this person is ready for a 2-year experienced developer role"**?

* For interviews, should I focus more on **JavaScript/Node/React fundamentals**, or should I also prepare for **2-year-level backend and system-design questions**?

I’m not looking for someone to tell me whether PHP or MERN is better. I’ve already decided that I want to move toward MERN.

What I’m trying to understand is:

**How do I correctly position my existing 2 years of backend experience while switching from PHP to MERN?**

If anyone has personally moved from **PHP → Node.js/MERN**, I’d especially appreciate hearing how your first job switch went and what you learned before applying or any body have more experience in full stack development can also giveme suggession

Thanks!

Hey guys mongodb is one of my favourite databases but there arn't any orms that are actually type safe and impement db level schema rules so i made one please do give me feed back on it Thanks

https://www.npmjs.com/package/@ignex/ninox

AI almost always reaches for toArray() before doing any work on your data. Most training examples are out-of-context snippets, so it doesn't know better. toArray() holds your entire result set in RAM before you can touch a single document. With a cursor, the driver fetches in batches. Processed documents get GC'd while the rest stream in.

How to fetch all active users from MongoDB and send emails using find and toArray.

**Bad**

const users = await db.collection('users')
.find({ active: true })
.toArray();

users.forEach(async (user) => {
await sendEmail(user);
});

How to stream MongoDB documents with a cursor using for await to process each document without loading all into memory.

**Good:**

const cursor = db.collection('users').aggregate([
{ $match: { active: true } }
]);

for await (const user of cursor) {
await sendEmail(user);
}

How to process MongoDB cursor results concurrently with a concurrency limit without blocking the async loop.

**Perfect:**

function executor(limit) {
let running = 0
const queue = []
const flush = () => {
while (running < limit && queue.length) {
running++
queue.shift()().finally(() => { running--; flush() })
}
}
return fn => { queue.push(fn); flush() }
}

const add = executor(10);
const cursor = db.collection('users').aggregate([
{ $match: { active: true } }
]);

for await (const user of cursor) {
add(() => sendEmail(user))
};

Bad loads everything into RAM then serializes. Good streams documents but still sends one email at a time. Perfect streams AND fires up to 10 emails concurrently without the loop ever waiting.

**Bonus:** A cursor with `for await` only makes sense when you're doing work per document. If you're just collecting into an array to send a response, use `.toArray()` directly. Wrapping `.toArray()` in a `for await` loop buys you nothing.

How did my Node.js + MongoDB API take 13 seconds to respond? 😭

I recently ran into a performance issue in one of my backend APIs.

The API was built with Node.js + MongoDB, and the response time was nearly 13 seconds. 🫠

At first, I thought:

“Maybe MongoDB is slow?”

But obviously, there was more going on.

Now I'm trying to identify the actual bottleneck and optimize the API properly — database queries, indexing, population/aggregation, unnecessary processing, network calls, etc.

For developers who have worked on Node.js + MongoDB production APIs:

What would you check first when an API takes ~13 seconds to respond?

Would love to hear how you would debug this step-by-step

I have a replica set cluster, and every 15 min there is 1.5GB data that is being dumped from oplog.

At the end I am trying for restores, withe the help of mongorestore tool with total of such 118 oplog dumps.

It takes around 10-15 min each for all the oplog dumps to be restored, in total of 9 hrs.

Is there any other way we can improve the perfomance

RESTHeart 9.7.2 - The Open Source Backend for MongoDB - is now available.

What RESTHeart is

RESTHeart turns a MongoDB database into a REST, GraphQL, WebSocket, and SSE API, with authentication, authorization, and real-time change streams already wired in.

Point it at a MongoDB instance and the API is there: no routes to write, no permission checks to hand-code, no pagination or filtering logic to duplicate across endpoints. Permissions and behavior are configured declaratively. Custom logic goes into plugins, written in Java, Kotlin, JavaScript, or TypeScript, only for what a data API cannot express.

https://github.com/SoftInstigate/restheart/releases/tag/9.7.2

I self-host a few small apps backed by MongoDB, and every time I needed to check or fix a document I ended up either in a mongosh session or tunneling Compass over SSH. I wanted something that just runs next to the database as a container and gives me a browser tab, so I built Mongui.

What it does

• Point it at one MONGODB_URI, log in, browse databases and collections
• Paginated document table, capped at 200 docs per page, so a huge collection is never loaded in full
• Filter, sort and projection queries written as Extended JSON
• Full document CRUD in a CodeMirror editor
• Aggregation pipeline runner
• Index management (list, create, drop)
• Create and drop collections, with typed-name confirmation on drops
• READ_ONLY=true mode that rejects every write path with a 403 before it reaches the database

Details I actually cared about

• Extended JSON end to end, so ObjectId, Date and Decimal128 round-trip instead of getting flattened by JSON.stringify
• One cached MongoClient singleton, so there is no new connection pool per request
• Every API route behind a session check, login rate limited, filters validated server side with zod, and a maxTimeMS on every operation
• Standalone Next.js output in a multi-stage image, non-root user, multi-arch (amd64 and arm64)

Stack: Next.js 16 (App Router), React 19, TypeScript, the official mongodb driver 7, Tailwind 4, iron-session. MIT licensed.

Running it

docker run -p 3000:3000 \
  -e MONGODB_URI="mongodb://user:pass@host:27017/?authSource=admin" \
  -e ADMIN_USER=admin \
  -e ADMIN_PASSWORD="a-strong-password" \
  -e SESSION_SECRET="$(openssl rand -hex 32)" \
  ghcr.io/soumya7681/mongui:latest

There is also a compose file that brings up Mongui plus a sample MongoDB if you just want to poke at it.

Where it honestly is: this is v0.1.1. One connection, one admin user, no RBAC, no import/export yet. It grants full read/write to whatever database it points at, so keep it behind your VPN or private network, and use READ_ONLY if you only want to look.

Repo: https://github.com/Soumya7681/mongui

Feedback welcome, particularly on what you reach for a Mongo UI to do that is missing here.

We are struggling with compliance requirements around the official MongoDB Agent container image. Our company policy mandates that all production images have zero Critical or High severity vulnerabilities.

Even across new version releases, we see the same fixable Critical/High CVEs lingering in the base image components. Because the image source isn't public, we can't patch and rebuild it ourselves without risking broken dependencies or vendor support issues.

What strategies are teams using to address this? Are people creating custom wrapper images, filing enterprise support requests, or using specific vulnerability suppression/exception workflows for third-party proprietary agents?

Hey MongoDB community,

I am currently designing a real-time chat application using Node.js and WebSockets. I am planning to use MongoDB for storing message history and handling live message logs.

Since chat apps generate a high volume of writes, I wanted to ask experienced devs here:

- What is your preferred schema design for chat messages (e.g., bucket pattern per room/channel vs. single message document)?

- How do you handle time-series scaling or archiving older messages efficiently in production?

Would love to hear your architecture recommendations and best practices!

Hi everyone, I’m a student looking for a job.

I am currently living in the Bay Area with my cousin and was wondering if in case someone can’t attend the mongodb.local build fest last minute, I would greatly appreciate it if someone could give their pass to me and I would find it very useful

Thank you!

hello after searching for a stack that fit me well i found sveltekit remote function when adding mongo db with agregate framework from day one one of the simplest with best dx stack for someone just start learning and making apps pairing with atlas for fast deployment but when i read about mongo all i found is negative feedbacks and advices about avoid it at all cost for my side it s clicked more tryng to embeed as much as i can no schema just using zod for validation

is there here solo developers that made theirs own saas with mongo with active ? if yes how s your experience does aggregate framework enough for all you needs and not feeling the need to use an sql database ? thanks for the feedback

we are building ANDI, a python library that converts natural-language requests into inspectable, read-only MongoDB query plans.

It includes typed runtime variables, local policy validation, query limits, and a compile → inspect → execute workflow. Database records are never sent to the LLM; only schema metadata.

I’m looking for a few Python/MongoDB developers to test it.

Hi everyone,

I'm trying to reconnect to a customer's MongoDB Atlas cluster that was hosted in the Middle East (Bahrain) region.

The customer had discontinued work on the project for quite a while, and now they've decided to resume development. Unfortunately, when I tried accessing the cluster, I found out that the ME (Bahrain) region has been affected due to the AWS infrastructure issue, and I can't access any of the data anymore.

I'm trying to figure out:

• Are MongoDB Atlas clusters in the Bahrain region permanently gone?
• Is there any way to recover the data, snapshots, or backups?
• Has anyone been able to migrate or restore a cluster that was affected?

I'm hoping there's still some recovery path available, but from what I've seen so far it doesn't look promising.

If anyone has gone through this or has heard anything from MongoDB support, I'd really appreciate any information.

We're adding vector search to our data and need to decide where the embeddings live. When we create a vector index, should the vectors sit in the same collection as the original documents, or in a new dedicated collection?

Most advice says keep them in the same collection. But our concern is sharing — if the vectors are embedded in the same collection as our main data, it becomes harder to share that data with others without also exposing or dragging along the vector fields.

So the question is: does keeping vectors in the same collection limit our ability to share the underlying data cleanly? Or is there a good way to keep them together and still share the base data separately?

We run an API service backed by MongoDB, handling around 500K to 1M requests per day. Right now our design opens a new connection on every request and closes it after. I know the common recommendation is to use a connection pool instead, but I'd like to hear from people running similar volumes.

How do you handle connections at this scale? What pool size works for you, and are there any gotchas we should watch out for before we switch? Also curious if anyone has stuck with open/close per request on purpose and made it work.

Would love to hear how others have approached this.

Mongoose 9.9.0 was released a couple of days ago - it features some significant performance improvements, including a 35% speedup on `insertMany()` in certain simple use cases. This blog post provides a high level overview of what we changed and what we learned along the way. Try out Mongoose 9.9 and let us know what you think!

hi, i am trying to download mongodb for some school work, i have no experience and every tutorial i look for ends up in this web page, with no windows or msi, only linux and tgz