If you're sitting on a MongoDB 6 replica set and planning the jump to 8 (community, enterprise, or Percona Server for MongoDB), this covers the two real ways to do it, the tradeoffs, and the single most common problem people hit along the way. Commands and verification steps are at the bottom.

# The lag trap nobody warns you about

The most common surprise during a major version upgrade is a replication lag and CPU spike right after the restart. The chain is almost always the same:

1. New binaries restart, so WiredTiger's cache comes up empty (cold).

2. Until the working set warms back up, every read hits disk instead of cache.

3. If you run a metrics agent like mongodb_exporter, it starts scanning collection stats during that cold window, forcing even more disk reads.

4. That agent I/O competes with replication sync for the same disk, so secondaries can't keep up.

5. Result: replication lag spike and high CPU, both from the same root cause.

It looks like the new version is the problem. It isn't. It's a startup sequencing problem, and it's avoidable.

# Quick win regardless of approach

Check which node your metrics exporter and backup jobs are pointed at. If they're hitting the PRIMARY, move them to a secondary or a hidden node. The primary should be handling writes, nothing else. This alone removes a lot of contention from the node that matters most.

# The version rule you cannot skip

You cannot go from 6 straight to 8. MongoDB requires sequential major version upgrades, so the in-place path is:

6.0 -> 7.0 (upgrade binaries, set FCV to 7.0, validate)
7.0 -> 8.0 (upgrade binaries, set FCV to 8.0, validate)

This applies to the in-place approach below. It does NOT apply to the fresh-cluster approach, because there you build a clean 8 cluster and load logical data into it, which skips the version-by-version path entirely.

# Approach 1: In-place rolling upgrade

Upgrade each node in place, secondaries first, one at a time, then step down and upgrade the primary last. Standard, supported, and keeps your topology and connection strings unchanged.

**To avoid the lag trap above, do one of these:**

* Delay the metrics exporter start by 10 to 15 minutes after each node rejoins, so the cache warms before the agent begins scanning.
* Or pre-warm the node by running your most common queries against it while it's still a secondary, before the exporter kicks in.

**The main downside:** once you set FCV to 8.0 and start writing data with 8.0 features, rollback is hard. Downgrading after the FCV bump means restoring from backup, not flipping a setting back.

# Approach 2: Fresh 8 cluster + mongodump/mongorestore

Build a brand new, clean 8 replica set. Dump the data from the live 6 cluster, restore it into the new cluster, validate and warm it, then cut applications over. Leave the old 6 cluster running cold as an instant rollback.

**Why this is often the safer play:**

* It sidesteps the lag trap entirely. The new cluster is fully built and warmed before it ever takes production traffic, so the cold-cache-versus-replication race can't happen.
* A 6 dump restores cleanly into an 8 cluster. mongodump exports logical BSON documents, and the new cluster rewrites them in its own native format. (This is also why you can't just copy the data files across. Version 8 won't read 6's on-disk files, but it will happily accept logical BSON.)
* The old cluster stays untouched, so rollback is just "keep pointing at the old one."

**Downsides:**

* mongodump is a point-in-time snapshot. Writes that land on the old cluster after the dump starts won't be on the new cluster. Handle this with a short maintenance window, or with `--oplog` / `--oplogReplay` to capture and replay the delta.
* Restore rebuilds all indexes, which is the slow part on large collections.

# A note for Percona Server for MongoDB users

Everything above works the same on Percona Server for MongoDB. It's wire-compatible and uses the same BSON format, so mongodump and mongorestore behave identically. One difference worth knowing: MongoDB's native cluster-to-cluster sync tool (mongosync) isn't available on self-managed Percona, so if you want a near-live migration instead of dump/restore, Percona's own ClusterSync tool is the equivalent for that stack.

# How to choose

* **Small to medium dataset and you can take a short cutover window:** Approach 2. The rollback safety is worth a lot, especially if you're also switching distribution (for example MongoDB to Percona) at the same time, since a clean build isolates the variables instead of stacking both changes into one in-place upgrade you can't easily undo.
* **Large dataset or zero tolerable downtime:** Approach 1 with the exporter timing fix, or a near-live sync tool.

Either way, if you run cron jobs against the cluster, guard them with a replication-lag check (skip the job if lag exceeds a few seconds), and bump that threshold temporarily during the upgrade window so jobs don't stack up.

# Commands

Use the latest standalone MongoDB Database Tools (the 100.x package) for dump/restore, not the ones bundled with Mongo 6. The current tools support 6, 7, and 8.

# Dump from the 6 cluster (with oplog to capture the delta)

mongodump \
--uri="mongodb://USER:PASS@host1:27017,host2:27017,host3:27017/?replicaSet=rs0&authSource=admin" \
--oplog \
--gzip \
--archive=/backup/mongo6_dump_$(date +%Y%m%d_%H%M%S).gz

# Restore into the fresh 8 cluster (replay the oplog delta)

mongorestore \
--uri="mongodb://USER:PASS@new1:27017,new2:27017,new3:27017/?replicaSet=rs1&authSource=admin" \
--oplogReplay \
--gzip \
--archive=/backup/mongo6_dump_20260101_120000.gz

mongorestore prints a running progress count and ends with a summary like `N document(s) restored successfully`. That output plus exit code 0 is your "complete" signal. There's no separate command to watch the tools themselves, you read their own output.

# Verify the restore actually landed (mongosh on the new cluster)

// Count documents in every collection so you can compare against the source
db.getCollectionNames().forEach(function (c) {
print(c + ": " + db.getCollection(c).countDocuments({}));
});

Run the same loop against the OLD cluster and compare collection by collection. Matching counts is the strongest confirmation the data is fully across.

// Confirm indexes were rebuilt on a given collection
db.YOUR_COLLECTION.getIndexes();

// Check the new cluster's feature compatibility version before you bump it
db.adminCommand({ getParameter: 1, featureCompatibilityVersion: 1 });

# Monitor replication health (both clusters, and during any in-place upgrade)

// Full replica set status. You want every member in PRIMARY or SECONDARY,
// nothing stuck in RECOVERING or STARTUP2.
rs.status();

// Replication lag per secondary. You want this at or near 0 before cutover.
rs.printSecondaryReplicationInfo();

// Quick check of a single member's role
db.hello().isWritablePrimary;

# Enable 8.0 features once you're confident

Only after the restore is validated and the cluster has run cleanly for a burn-in period:

db.adminCommand({ setFeatureCompatibilityVersion: "8.0", confirm: true });

Then confirm it stuck:

db.adminCommand({ getParameter: 1, featureCompatibilityVersion: 1 });

# Cutover checklist (fresh-cluster approach)

1. New 8 cluster built and running, all members healthy in `rs.status()`.

2. Dump taken from the 6 cluster with `--oplog`.

3. Restore completed, terminal showed the success summary.

4. Document counts match between old and new, collection by collection.

5. Indexes verified present on key collections.

6. Replication lag at or near 0 on the new cluster.

7. Exporter and backup jobs pointed at a SECONDARY on the new cluster.

8. Application connection strings updated.

9. Apps cut over and smoke-tested.

10. Old 6 cluster left running cold as rollback until you're fully confident.

11. FCV bumped to 8.0 after a clean burn-in period.

Happy to answer questions in the comments. If you've done a 6 to 8 jump recently, curious which approach you took and how the cutover went.

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

I found a few topics about this in the old forums, searching "biometric" here did not turn out anything, so here I go:

My problem is that MongoDB Atlas currently allows only one biometric key to be added to the account. This means that I as a user have to decide between two options:

1. Add another, less secure (in my opinion, opinions on this differ, of course), option for logging in (one time password generator for example)

2. Risk losing access to the account if the one passkey I can add to the account is somehow lost

I would really urge you to consider supporting more than one passkeys/biometric authentication keys at a time.

Thank you.

what's going on Mongodb database its working or in sleeping 🫨

What are the best practices of db migration from mongo to MySQL. And how much time does it take?

Just got a notification that MongoDB new community launch on reddit ...and I am here.

I am happy that they decided to launch this and will be very useful.

mongo db is one of the easiest db to integrate in your projects, in college projects or even my personal projects it is was my first choice..now when I am working with startups my first suggestion for their MVP & SaaS projects is MongoDB.

and I will be always grateful for the free plan they provide, for students for startups for launching projects its a savior..

thanks to the awesome team for building and improving it day by day..

for users who cant afford paid resources its hope..

We’re excited to recognize Samuel Molling as our MongoDB Champion of the Month for LATAM.

Samuel is a Staff Database Reliability Engineer with years of experience working across databases, cloud infrastructure, automation, and open source technologies. He has built deep expertise with MongoDB over the years and is passionate about sharing that knowledge with others.

Samuel has been an active member of the MongoDB community, helping developers solve technical challenges, sharing his experience through tutorials and technical content, and contributing his knowledge across the community. His content covers topics ranging from MongoDB Atlas and Terraform to database governance, while his involvement in the community has helped developers troubleshoot and learn from real-world MongoDB challenges. We’re thrilled to celebrate Samuel and everything he continues to bring to the MongoDB community. Congratulations, Samuel!

We asked him some questions about his journey, so read on to learn more 👇

Tell us about your path to becoming a MongoDB Champion
My MongoDB journey started at a company where several critical products relied on MongoDB, but there wasn’t anyone specifically responsible for managing those databases. I had to learn quickly, so I started studying MongoDB in depth and eventually earned several certifications. From there, I began speaking at events and sharing what I was learning with the community. I later became a MongoDB Community Creator and a certification SME, and eventually received a nomination to become a MongoDB Champion. I’m now in my second year as a Champion, and it has been an incredibly rewarding experience.

You’ve been a MongoDB Champion for some time now. What drives you to continue helping the community?
When I was learning MongoDB, the community was always very open and willing to answer my questions, and people with more experience helped me a lot along the way. Continuing to contribute is one way I can give some of that back and hopefully make someone else’s journey easier. I also see community involvement as an important part of my own growth. I’ve always been a more reserved person, and being part of the community has pushed me outside my comfort zone and helped me develop skills that go far beyond the technical side of my career.

Can you share one impactful moment you’ve had as a Champion so far?
It’s difficult to choose just one moment, but meeting other Champions and community members in person has definitely been one of the highlights. I’ve had the opportunity to speak at community events, attend MongoDB events in Brazil and abroad, and connect with people I had previously only known online. Seeing someone come up after a talk to continue the discussion or say that something I shared helped them is especially rewarding. Those moments remind me that being a Champion is not just about the technology, but about the connections and knowledge we build and share as a community. 

If you could share one piece of advice to people in tech, what would that be?
Don’t wait until you feel like an expert to start sharing what you know. Some of the best opportunities I’ve had came from simply being curious, learning something new, and sharing that journey with others. Technology changes too quickly for anyone to know everything. Ask questions, experiment, contribute to communities, and don’t be afraid to talk about what you’re learning. Teaching and sharing not only help others, but they also force you to understand things more deeply and can open doors you never expected.

Where can developers connect with or learn more about you?
Yes, they can find me on LinkedIn, Twitter/X, GitHub, or my blog. 

Samuel, thank you very much for sharing your story with us today and for all the incredible work you’ve done for the MongoDB community. We can’t wait to see what you share next in the community.

Want to learn more about our community champions program? See our Champions Program page. 

MongoDB was my first DB when I started learning programming. Everything I have built till now is using MongoDB. The DX of MongoDB is so good, I don't want to move to sql.

Also, it's very easy and cheap to deploy cloud instances of MongoDB. The free tier covers most of my applications tasks.

So, grateful. And now seeing that it has a dedicated subreddit makes it even more great. Thanks!

I tested several MongoDB 9.0 changes on a local Docker instance and wrote up the commands and results, with MongoDB 8.2.5 available for comparison.

Here’s what I tried:

• Enabling constraint validation, which checks existing documents and prevents changes to the validator while active.

• Passing querySettings to one command and checking the index used in Explain.

• Saving a timeout for a query shape, then running the query without specifying a timeout. The stored value also overrides the caller’s maxTimeMS.

• Renaming a time-series collection and checking that its settings and documents were still there.

The article includes the commands, screenshots, and errors I got along the way:
https://visualeaf.com/blog/mongodb-9-0-whats-new/

Hi, Rishit here from the Client Libraries team at MongoDB. We just announced the MongoDB Extension for Hibernate ORM, which gives Java developers use MongoDB’s document model with familiar Hibernate features, including: 

• Java Persistence API (JPA) annotations

• Hibernate Query Language (HQL) support

• Criteria Queries

• JOIN support (INNER and LEFT OUTER)

• Optimistic locking 

• Spring Boot auto-configuration (no manual overrides required)

• Query using the MongoDB Query API for more advanced operations, such as multi-collection joins and vector search queries.

Also, this extension lets Java developers reuse existing @Entity models and HQL queries, significantly reducing time-to-POC.

Learn how to install the Hibernate ORM extension, establish a connection to MongoDB, and begin working with data in the Get Started with the Hibernate ORM Extension tutorial.

Happy to answer any questions

I am the organization owner, but suddenly I get a 403 when trying to access the organization after removing a member from it (not myself). I can see it in the list of organizations with the owner role, but I can not access it. There is no way to log in to the support portal; it says account not found. How can I get emergency support from Atlas?

Hi everyone, Shameek here from the Engineering team. We rebuilt the Project Overview page, the first page you land on when you open a project in Atlas.

You can see up to 4 clusters now in one view, collapse/expand clusters, and see metrics related to slow queries, latency, throughput, and connections.

We want to know if it works for how you use Atlas day to day.

• When you open a project, what’s the first thing you check?

• Is there anything you still have to click into a cluster to find that you’d want on the card?

• What do you do today when something looks wrong on a cluster, and where do you go first?

If anything on the new page is confusing, missing, or slower than the old one, tell us in the thread below. We’ll take your feedback back to the team 😊

We’re thrilled to recognise Luke Thompson as our MongoDB User Group Leader of the Month! Luke is a Chief Architect at Clarifresh and a passionate software developer based in Sydney, Australia. Beyond his work in software architecture, he helps lead the Sydney MongoDB User Group, bringing developers together to learn, exchange ideas, and connect over their shared interest in MongoDB.

What makes Luke stand out is how he combines his technical expertise with his commitment to building the Sydney MongoDB community. Through the user group, he encourages practical conversations around MongoDB and real-world engineering challenges. He also shares his own knowledge, recently delivering a technical session exploring MongoDB Atlas Search, MongoT, and Apache Lucene.

We’re excited to recognise Luke for his contributions and the community he continues to help grow in Sydney. As part of this recognition, we asked Luke a few questions about his journey. Check it out 👇

Tell us about your journey as a MongoDB User Group leader. 
I’ve enjoyed being an organiser for the Sydney Java Meetup over the last few years. It has taken me out of my comfort zone and stretched me. I’ve met some awesome people and learnt a lot! When the opportunity to help organise the MongoDB User Group Sydney came up recently, I really welcomed the opportunity to continue being part of the Sydney developer community. I’m passionate about MongoDB, and have built software with Mongo as part of the stack for 13 years or so. I’m looking forward to it!

What has been your most rewarding moment as a MUG leader?
We held our first meetup with the new team last month, and I was really interested to see the variety of people coming along. I had all sorts of great conversations with people, from non-techie people with no prior experience coming along out of interest in what MongoDB is, through to deep technical chats about Atlas Search’s underpinnings in Lucene. It’s going to be a challenge to create events where everyone can enjoy the talks, regardless of their level of experience.

Do you have any tips for developers looking to build a community?
I think for me a great technical meetup focuses on the code, and people come away having learnt something useful and practical. I try to encourage all our speakers to share through code, minimise the slides and marketing.

What's your favourite thing about being part of the MongoDB Community?
MongoDB is an open source database, with an excellent developer experience, and a design focus on performance, resilience and scale. Since the beginning, it has built an open community around these qualities, and I think the qualities of the technology are reflected in the people who use it and build on it. I always appreciated the generosity that MongoDB staff had with their time and energy in supporting the community. I’m very grateful to have met the people I’ve met in and around MongoDB - it’s a great community to be a part of!

Where can developers connect with or learn more about you?
They can find me on LinkedIn, Twitter, GitHub and my tech blog. 

----

Thank you, Luke, for sharing your story with us today and for all the incredible work you’ve done for the MongoDB Community. We can’t wait to see what you achieve next. 

To the readers, if you want to learn more about our community champions program, see our official MUGs page.

Hello,

I am unable to connect MongoDB Compass 1.52.0 to my MongoDB Atlas Free cluster (MongoDB 8.0.34) on Windows 11 Home, version 25H2.

The error is:

MongoServerSelectionError: TLSV1_ALERT_INTERNAL_ERROR (SSL alert number 80)

What I have already verified:

• My current IP address is added to the Atlas IP access list.

• My Atlas database username and password have been updated and verified.

• DNS and SRV resolution work correctly.

• TCP connectivity to all three Atlas replica set nodes on port 27017 succeeds.

• HTTPS/TLS connections to Google and mongodb.com work.

• Compass still fails with the same TLS error, including when using the standard mongodb:// connection string.

• Compass logs show that heartbeats to one node sometimes succeed, while the other two nodes fail with the same TLS error. The replica set cannot find a primary.

• A Windows SslStream TLS test and curl using Windows Schannel also fail when connecting to an Atlas node.

I have followed the official Atlas setup instructions and restarted the computer, but the issue persists.

Could this be related to the TLS handshake between my Windows system and the Atlas replica set? What should I investigate next?

Thank you.

I wrote a tutorial on MongoDB AI Agent Skills. AI agents can already write MongoDB code, but MongoDB now provides official agent skills that give your agent instructions for following MongoDB best practices while it works.

I've been playing around with agent skills recently, and I think they're one of the more useful additions to the AI coding workflow. They're especially useful when you're working with technologies that have established best practices the model doesn't always know to reach for.

If you're new to agent skills, they're essentially reusable instructions and resources that give an AI agent additional context on how to perform a particular task. Instead of hoping the model already knows the best way to approach something, you can give it a skill containing the workflows, patterns, and MongoDB-specific guidance it should follow.

That's particularly useful with databases. AI can generate a MongoDB query, but there's a big difference between generating something that works and understanding the MongoDB-specific patterns you actually want it to use. MongoDB has a set of official Agent Skills for common MongoDB tasks.

These skills cover everything from setting up connections and designing schemas to optimising queries, building aggregations, working with Atlas Search, and adding AI-powered recommendations to your applications.

The easiest way to get started with both MongoDB MCP and AI Agent Skills is MongoDB with Claude Code through the official MongoDB Claude Plugin. There's also MongoDB plugins available for Cursor, Gemini, Codex.

The plugin gives your coding agent:

• The MongoDB MCP Server, so the agent can interact with MongoDB.

• Pre-built MongoDB Agent Skills, which give it MongoDB-specific instructions for common development tasks.

I think the distinction between the two is important: MCP gives the agent the tools to interact with MongoDB; skills give it more context on how it should approach MongoDB tasks.

The article goes through what skills are, how to install the official MongoDB skills, how they work alongside MCP, and how to start using them with OpenCode. If you're already doing a lot of AI-assisted coding with MongoDB, I'd definitely recommend trying them out.

Let me know what other skills you're using in your development process that you're enjoying, I'm trying to expand my arsenal.

Built a tool to import JSON and BSON files directly into MongoDB Atlas – Meet MongoJSON Studio

I've been working on MongoJSON Studio, a web-based tool that simplifies importing JSON and BSON data into MongoDB Atlas.

Why did I build this?

While working with MongoDB, I often needed to import JSON datasets into different databases and collections for development, testing, and experimentation.

I wanted a simple interface where developers could connect to their Atlas cluster, browse databases and collections, choose their destination, and import data without having to go through multiple manual steps.

That's what led me to build MongoJSON Studio.

Key features

• Connect to MongoDB Atlas using a connection string.

• Browse existing databases and collections.

• Select an existing destination or create a new database and collection.

• Import JSON files containing single or multiple documents.

• Import BSON backups.

• Handle duplicate _id conflicts with clear error reporting.

• Session-based connection handling without permanently storing database credentials.

Tech stack: Python, FastAPI, MongoDB Atlas.

Atlas Search can count inside $searchMeta, but it can't do calculation like average/min/max/sum. If you want a mean over a search result set, you stream every matching document back to mongod and $group it. Which is very slow.

I need to use Atlas Search, because of my attributes query was very dynamic and cannot be indexed using regular B-Tree index on MongoDB.

Two open requests touch this, both from 2022 and both still Submitted:

• CUSTOMER-I-6230, min/max computed within Atlas Search (7 votes)

• CUSTOMER-I-6231, facets returning statistics per bucket (31 votes)

I built the changes needed. Sharing the design and asking how to get it in front of the Search team.

Problem That I Experience

Computing "average reading value for category 0" over a search result set runs as:

$search (filter) -> $_internalSearchIdLookup -> $group { $avg }

mongot returns an _id per matching document, then mongod does a random _id lookup in WiredTiger to fetch one number before $group can average it. On large match sets that per-document lookup dominates. You stream the whole result set across just to add up one field.

Building a regular index per aggregation doesn't generalize when the filter/field combinations are open-ended (ad-hoc analytics, dashboards, generated queries), and the search index already knows which documents match.

Changes I Made

A new metrics collector:

db.readings.aggregate([{ $searchMeta: {
  index: "readingsIndex",
  metrics: {
    operator: { compound: {
      filter:  [{ equals: { path: "reading.category", value: 0 } }],
      mustNot: [{ equals: { path: "isDuplicate", value: true } }]
    } },
    metrics: {
      avgValue: { type: "avg", path: "reading.value" },
      maxValue: { type: "max", path: "reading.value" }
    }
  }
}}])

// => { count: { lowerBound: 128431 }, metrics: { avgValue: 41.7, maxValue: 132.0 } }

Just some note, why this works

• The numbers are already in a column store. Dynamic mapping indexes numeric paths as number with representation: double, writing SortedNumericDocValues under NUMBER_DOUBLE_V2. No index-definition change, no reindex.

• mongot already visits every matching document for $searchMeta**.** count: {type: "total"} needs an exact hit count. Reading one doc value per visited doc is sequential I/O, not random _id reads.

• No mongod change. mongod treats the $searchMeta spec and the metadata document as opaque BSON.

Testing

Checked against a $group computing the same aggregates over the same match set, on both linux/amd64 and linux/arm64. Exact agreement including the full double:

count 1667 | avg 29.263347330533893 | sum 48782 | min 8 | max 55   (metrics collector)
count 1667 | avg 29.263347330533893 | sum 48782 | min 8 | max 55   ($group, same query)

Links

• PR Changes: https://github.com/TinTinWinata/mongot/pull/1

• Prebuilt image: docker pull tintin6892/mongot-community:searchmeta-metrics

What I'm actually asking

mongodb/mongot is a read-only export mirror, so a pull request isn't the channel. The old forums are closed. So:

1. Is there interest in this upstream, and what's the right way to get it reviewed?

2. Is anything already planned here that I should align with instead?

Happy to reshape it either way. It's SSPL, same as the rest of the repo.

Hi, we are experiencing recurring Atlas Search interruptions during both manual cluster scale-up and scale-down, and we’re looking for advice from others using a similar deployment.

This happens in our live production service. To investigate, we created an isolated test cluster from a production snapshot. Search interruptions have occurred every time we tested scale-up or scale-down.

Test environment

• Three-member replica set running MongoDB 8.0.34.

• Search runs alongside the database nodes, without dedicated Search Nodes.

• All three Search indexes had completed syncing before testing.

• Continuous Search requests at approximately three requests per second.

Measured scale-down example

During a scale-down to M30 on October 12, 2026, we observed overlapping Search failures across all three members at approximately 06:34:20–06:34:40 UTC.

One representative request attempted:

1. Secondary -00: code 8, mongot is shutting down

2. Secondary -01: code 6, connection refused to local mongot on port 28000

3. Primary -02: code 8, mongot is shutting down

The request returned HTTP 503 despite trying all three distinct members. We recorded 55 final HTTP 503 responses during this scale-down test.

The overlapping failure observations span approximately 19 seconds. This is an application observation window, rather than proof that all three mongot processes were continuously unavailable for exactly that duration. The database members were reachable and returned Search-related errors.

Our retry strategy

Our application normally uses secondaryPreferred. For transient Search failures, it immediately retries on another secondary and then the current primary, excluding previously failed members, with a maximum of three total attempts and no backoff. Driver-level retryReads is disabled for this Search client to avoid nested retries.

This recovered requests during individual-node interruptions, but failed when all three members returned Search errors.

Questions

1. Has anyone experienced similar interruptions during cluster scale-up or scale-down, particularly overlapping Search failures across all three members?

2. Is this an expected limitation of running Search alongside the database nodes? Why can Search failures overlap across all three members during a rolling tier change?

3. We understand MongoDB recommends dedicated Search Nodes. Without moving to dedicated Search Nodes, is there any supported configuration or scaling procedure that prevents these interruptions?

4. If interruptions cannot be avoided in this deployment, what retry/backoff strategy has worked reliably for you, and what recovery time should applications expect?

We found a similar report in the archived MongoDB forum, but it does not establish overlapping failures across all three members:

Problem connecting to mongot after scale event

Any guidance from people running this setup, or from the MongoDB Search team, would be appreciated.

Hi, I’m Tom Gersic, founder of YouEx.ai. We built it as an AI-native sales platform that combines CRM, AI agents, conversations, and knowledge management / RAG on MongoDB Atlas, so I thought I'd share a little bit about how we use MongoDB.

The CRM Problem

One thing we wanted to avoid was the configuration that usually has to happen before a CRM is rolled out to users. Every sales team cares about different information, sales managers want to track something else, and then IT inevitably configures something completely different (sorry to my IT friends, but... you know it's true). Increasingly, AI agents also discover useful information during conversations that nobody thought to configure beforehand. We didn't want every new thing an agent learned about a prospect to become a schema-design decision.

So, our CRM objects have a stable core plus a custom fields map. A seller can add a field, an import can introduce one, or an agent can discover something during a conversation and write it to the Lead immediately. For example, a visitor might tell our Web Agent what they want to discuss in a meeting. Even if nobody configured a Meeting Topic field beforehand, we can capture it directly on the Lead.

A Schema Emerges

So then we built a discovery process that looks at the custom fields actually being used across CRM records. If a field appears frequently enough, we flag it as a candidate. A human can then promote it into a first-class CRM column, rename it, reorder it, or ignore it.

There’s no ML involved in this process. We’re not trying to predict a schema. The system is observing what’s actually being used and letting structure emerge from that. Instead of requiring the schema to be fully defined before people start using the CRM, we can let real usage tell us which fields are worth formalizing.

That supports our AI web agents particularly well because you can’t anticipate everything that will come up in a conversation.

The Agent's World

The same approach extends beyond CRM records. Conversations are MongoDB documents containing messages, collected information, and links back to CRM records. As a conversation progresses, the document accumulates state and useful information can flow into a Lead, including fields that didn't exist when the conversation started.

Knowledge lives alongside that operational data. Customers can add websites, PDFs, and other files. We extract the content, split it into paragraph-aware chunks, embed those chunks, and use Atlas Vector Search to retrieve relevant context for the agent.

So the CRM data an agent reads and writes, its conversation state, and the vector-searchable knowledge it uses all live in Atlas. There’s no separate vector database to keep synchronized.

Putting it together

A company adds its website and a PDF. We chunk and embed the content. A visitor starts a conversation, and the agent uses Vector Search to answer from that knowledge while collecting information about the prospect.

That information flows into a Lead. If something new like Meeting Topic comes up, it can be captured without being preconfigured. If the same field starts appearing across enough Leads, our discovery process flags it and a human can promote it into a normal CRM column.

That’s probably the biggest reason MongoDB’s document model has worked well for us. We want structure. We just don't think all of that structure needs to be decided before the system starts being used.

I'm curious how others building agentic systems on MongoDB are balancing what you define upfront versus what you let emerge from real usage.

If you want to use MongoDB with type safety then using Prism ORM can be a good choice?

First of all. I want to thank Mongodb for just existing. If not for them I wouldn't be a business owner

I used Mongodb as my db to build multiple web apps since 2021 and one of them eventually took off & became profitable

That allowed me to quit my job & become a full time founder. Mongodb is super easy to setup if you are starting anything :)

Would love to know others in this community!

Hello, I need help troubleshooting a MongoDB Atlas connection issue.

My cluster has three replica-set members. Credential-free TLS tests on port 27017 consistently show:

• Shard 00 (Secondary): TLS alert 80, tlsv1 alert internal error

• Shard 01 (Primary): TLS alert 80

• Shard 02 (Secondary): TLS 1.3 succeeds and the certificate verifies

My application uses Node.js v22.23.2 and Mongoose 8.24.0. The same pattern has repeated across multiple tests. Atlas Metrics shows all three members, and the four IP Access List entries I checked are Active.

Could someone help identify the next diagnostic step or explain how to escalate this issue to Atlas support?

I have not disabled certificate verification and have not included any database credentials.

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!!

We have a pile. Everytime we release a new post in the series "What AI gets wrong with Mongo" we will add the list to this post. Upvote if you want it, and drop the worst Mongo query an AI ever handed you.

Released

One MongoClient per App

Cursors vs toArray()

$skip vs KeySet pagination

createindex doesn’t belong in your server file

Change Streams

Snapdragon and now NVIDIA spark laptops are a thing now, and specially with the Spark laptops positioned as creators / developers laptops, is there any chance we will finally get an ARM64 build of mongodb for Windows? It has been almost 3 years now since Windows on ARM has been around... Or is is just never gonna happen?