I wanted to see if my service was doing something stupid before I shipped it, so I built mongosnoop using an ebpf engine. source if you want it

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?

I tried installing the latest version of mongoDB and then when i tried installing it showed error like - "service MONGODB server failed to start. Verify that you have sufficient privileges to start the system services". I tried going to cmd and run the installation as administrator and also going to service.msc and starting it manually but there also i get error. Pleas give any solution.

Need real reviews and suggestions. I tried to solve the real problems I face day to day on my own. Your feedback and suggestion is appreciated.

https://ognom.dev/

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.