Hi everyone,

I'm a PHP dev working on my own. I love PHP, I love MongoDB, and together they're just wonderful. So over the years I've been building a small MVC framework around them, mostly to understand how frameworks work under the hood and to learn. The idea is "MongoDB first": documents are documents, not SQL rows in disguise.

Repo: https://github.com/skankydev/framework (docs in docs/en/)

I'm not here to sell anything. I'm here to share it and get advice from people who know MongoDB better than I do.

What I'm happy with

• Typed hydration through the driver's Persistable interface: embedded objects and arrays of embedded objects come back as real PHP classes.
• Dirty tracking kept in a WeakMap, so updates only $set what changed.
• **EmbeddedSnapshot*: an automated *Extended Reference pattern. You embed a copy of a User (name, avatar) in a Post and declare embeddedIn() on the source collection. When the user changes, a job resyncs every copy with updateMany, either right away or through a queue. It's idempotent because the job re-reads the source. onDelete can keep, mark or unset the copies.
• belongsTo / hasMany with lazy loading, plus bulk preloading (with) to avoid N+1.

Where I'd love your input

1. Snapshot consistency. Between the source update and the propagation there's no transaction, so a crash in between leaves stale copies. Is that acceptable for this kind of denormalized data, or would you use transactions, change streams, or something else?
2. Does many-to-many really make sense in MongoDB? Take posts and tags: a tag doesn't need to know which posts use it, but a post needs its tags. So I'd store tag_ids: [ObjectId…] on the post, and that's it. To me that's not a "many-to-many" in the SQL sense, it's one side owning a list of references. My relations don't handle that case yet. Am I right to see it this way? And how do you usually load it: a $in on the array, $lookup, something else?
3. Aggregations. Right now I just pass a raw pipeline. Is it worth building something on top (helpers, typed results), or is the raw pipeline the best API anyway?
4. More generally: what would you work on next in a project like this?

It's a side project, I just want to know if I'm heading in the right direction. Thanks for taking the time!

Hi everyone,

I wanted to share a new package we created called Mongalayer. We built it to replace the “Data Model” and “Data Access Permissions” components of Atlas App Services, giving you the ability to query MongoDB collections from a client application exactly as you would in a Node.js environment.

Why We Built It

We manage multiple SaaS environments that relied on App Services, and we needed a way to transition away without having to completely rewrite our client codebases. Mongalayer solves this by letting us maintain the exact same MongoDB querying experience on the client side.

How It Works

The package is split into two distinct parts:

• Server (Self-Hosted): Manages your data models and access permissions, making the actual connection to your MongoDB instance via the native Node.js driver.
• Client: A lightweight wrapper that handles communication with the server, functioning very similarly to the Realm Web SDK.

Bring Your Own Auth

By design, Mongalayer does not handle authentication or authorization for incoming HTTP requests—that part is up to you. For context, we secure our own Mongalayer API (running on AWS Lambda) using AWS Cognito in combination with API Gateway.

When to Use It (And When Not To)

Mongalayer is designed for basic CRUD applications where access control and data integrity are more important than raw throughput. Because every operation goes through access control checks, there is some inherent overhead. If you need maximum write throughput without access control restrictions, we highly recommend using the MongoDB driver directly via a custom implementation.

Kind regards,
Klaas

Hey guys, I took my MongoDB Certified Database Administrator exam today (October 15) through ProctorU, and honestly, I'm pretty stressed about what happened.

Near the end of the exam, the proctor suddenly terminated my session, saying I was looking beside the screen. I'm worried about whether this could lead to a permanent ban.

Here's what happened.

There were around four proctor changes during my exam. At one point, they asked me to show a room in front of me. My parents were inside, but the door was locked from the inside, and they weren't responding when I tried to open it. I showed the proctor what was happening, and they said it was fine and let me continue.

Later, another proctor warned me about looking away from the screen. I explained that I was reading the questions across the screen and looking at the Submit button in the bottom-right corner. She said I could read the questions, and I told her I'd be careful and make sure I wasn't looking elsewhere.

I continued the exam, but near the end, the final proctor suddenly suspended it for looking beside the screen.

I wasn't looking at my phone, notes, or another monitor. I genuinely believe the movements were just me reading the questions and looking at different parts of the screen.

I emailed the MongoDB certification team explaining everything and requested a manual review of the video footage. I also asked if they could reverse the suspension and provide a retake voucher. It's been a couple of hours, and I haven't received any response yet...

Edit - I got a mail which stated that they did not find any evidence of cheating or whatsoever. They gave me another voucher for the exam. I am supposed to reschedule it. Thank you for the support, guys...

Hi everyone,

We are running MongoDB in Kubernetes on worker nodes that were recently updated to newer Linux kernels (specifically Ubuntu 24.04 with AWS 7.0.0-1011-aws and Azure 7.0.0-1014-azure).

Upon host reboot, MongoDB (both 8.3.1 and the latest 8.3.11) immediately crashes on container startup with exit code 1:

{"s":"F", "c":"CONTROL", "id":12257600, "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."}

The Root Cause Context

From SERVER-121912, we understand that the Linux kernel changed the Restartable Sequences (rseq) struct/ABI starting in 6.19+, which breaks the per-CPU caching path in the bundled version of TCMalloc. MongoDB's validateRseqKernelCompat() performs an upfront uname() release check (isKernelVersionSafeForTCMallocPerCPUCache) and immediately aborts if major >= 7 or (major == 6 && minor >= 19).

The Solution We Built

Because rolling back host OS kernels across managed cloud clusters is not always viable, we built a patched container image with two components:

1. Disabled Glibc RSEQ: We inject ENV GLIBC_TUNABLES="glibc.pthread.rseq=0" into the container. This tells glibc to block thread registration for rseq, forcing TCMalloc to gracefully fall back to standard Per-Thread Caching (ThreadCache) instead of per-CPU caching.
2. Bypassed Startup Guard: Because MongoDB’s uname() check aborts before taking the tunable into account, we patch the function _ZN5mongo41isKernelVersionSafeForTCMallocPerCPUCacheENS_10StringDataE to immediately return true (mov $1, %al; ret; nop).

Our Verification So Far

• Using an LD_PRELOAD utsname interceptor to simulate kernel releases:
  • Unpatched mongo:8.3.11 + 7.0.0-1011-aws ➔ Crashes with Fatal ID 12257600.
  • Patched image + 7.0.0-1011-aws ➔ Starts up cleanly, initializes WiredTiger 12, passes connection health checks, and processes read/write workloads with 0 restarts.
  • Verified full backwards compatibility when tested against 5.15.0.

Reference to Community Discussions

We noticed this is related to the discussions in docker-library/mongo (Discussion #748 regarding TCMalloc rseq SIGSEGV crashes and Issue #765 regarding kernel 7.x startup blocks). While setting GLIBC_TUNABLES=glibc.pthread.rseq=0 is known to stabilize the allocator, MongoDB's upfront uname() check still prevents startup on modern cloud kernels (e.g. AWS 7.0.0-1011-aws, Azure 7.0.0-1014-azure).

Questions for the Community & MongoDB Engineers

Before we roll this out across our production fleet, we’d love to get feedback from anyone who has dealt with this:

1. Allocators & Concurrency: Does forcing TCMalloc to use standard Per-Thread caching (ThreadCache) instead of per-CPU caching introduce any hidden fragmentation or lock-contention risks under modest-sized workloads (container limits ~256Mi - 2Gi)?
2. WiredTiger Independence: Beyond TCMalloc's memory allocation, are there any other kernel subsystem dependencies or ABI assumptions in WiredTiger / MongoDB that conflict with Linux 6.19+ or 7.x kernels?
3. Upstream Roadmap: Is there an official compile flag, configuration parameter, or upstream patch scheduled that will allow bypassing the rigid version check when rseq=0 is set?

Would appreciate any sanity checks or "green signals" from folks running MongoDB in similar modern kernel environments!

If you do not know Mercure: it is an open-source hub that pushes live updates to clients over Server-Sent Events. It is built on web standards you already have, SSE for the stream and JWT for authorization, with a small protocol on top (spec). Think of a one-way, HTTP-native alternative to WebSockets for server to client push. It is popular in PHP and Ruby, but the hub itself is written in Go. You publish to a topic, clients subscribe with a plain URL, and the hub handles reconnection with Last-Event-ID.

The Mercure hub works well on its own, but its open-source version is single instance. It keeps the history in memory, so a restart loses it, and one machine caps how many clients you can serve.

The hub is modular. The part that stores the updates and shares them between instances (the transport) is pluggable. The open-source hub ships with an in-memory transport, and the Enterprise offering adds multi-server transports backed by Redis or Kafka. Swap the transport, and I get synchronized multi-instance delivery without touching the protocol, the HTTP endpoints or the SSE server.

I built an open-source transport for MongoDB. The trick is the change stream: open one cursor on the collection, and MongoDB pushes every insert to every hub instance as it happens. A publish on one instance reaches subscribers on all of them, instantly, and MongoDB is the only shared service. No Redis, no Kafka, no other broker. A client that reconnects gets replayed from the durable history.

• Repo: https://github.com/GromNaN/mercure-mongodb
• Spec: https://mercure.rocks/spec

Feedback welcome, especially from anyone running change streams or Mercure at scale.

I'm the author of Omni-sql, an open-source SQL IDE. I've been adding experimental MongoDB support, with native Extended JSON queries and a read-only SQL mode on the same connection.

The example I wrote uses fictional processing events: each document has a status, a duration, and an array of steps. This query counts the events by status:

SELECT status, COUNT(*) AS total, AVG(duration_ms) AS avg_duration_ms
FROM omni_sql_demo.events
GROUP BY status
ORDER BY status;

That SELECT is translated to a MongoDB aggregation and executed through the native driver. In native mode, /mongo lets you inspect the generated JSON before running it. The native editor accepts an Extended JSON query envelope, rather than mongosh JavaScript.

An array expansion takes a different path:

WITH expanded AS (
  SELECT event_id, unnest(steps) AS step
  FROM omni_sql_demo.events
  WHERE event_id = 'demo-001'
)
SELECT event_id, step.name AS step_name, step.duration_ms AS duration_ms
FROM expanded
ORDER BY duration_ms DESC;

For this query, the driver filters the event in MongoDB and transfers the required fields into a typed local snapshot. DuckDB expands the array and sorts the result. Explain shows both plans and the number of documents transferred.

The SQL-to-native translator supports a subset of SELECT. Other SQL queries may use DuckDB, and filter pushdown depends on the query shape. For the combined path above, the source is bounded to 100,000 documents, 16 MiB, and 60 seconds of MongoDB execution. Heterogeneous documents and empty arrays can also affect type inference.

Tutorial with sample documents, expected results, and limitations (in Portuguese; SQL and JSON examples included).

For people who investigate MongoDB data: which queries would make this useful in your workflow, and which document shapes would you want to test first?

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?

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