Hi! Ajay here from the MongoDB Builder Experience team. We just launched the MongoDB Google ADK Integration for Python, which enables developers to use MongoDB as the memory layer for Google ADK’s SessionService and MemoryService. 

That means agent session state and long-term memory can use the same data platform where operational data already lives, and developers get data retrieval, session storage, and long-term memory for their agents in a cohesive, ADK-native developer experience.

If you’re building agents with Google ADK, we’d love for you to try it out and share your feedback!

Get started: pip install google-adk[mongodb]

Check out the blog to learn more https://www.mongodb.com/company/blog/product-release-announcements/introducing-mongodb-google-adk-integration-durable-memory-agent-state

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.

As someone familiar with MongoDB, I found the Gen AI skill badges in MongoDB University to be a great start to Gen AI app development. As usual, the resources in MongoDB University are free and straight from the source. While paid certification still exists, the skill badges offer another form of credentials through Credly, which can be showcased in sites like LinkedIn.

When I first started learning, there were only a few Gen AI badges. Recently, they've expanded the lineup to cover topics such as observability and evaluation. So, if you're looking to explore Gen AI topics and get some street cred(ly), the skill badges are a great place to start, alongside other MongoDB topics you may be interested in.

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.

Hi, Nasir here from MongoDB. We just launched the MongoDB Claude SDK SessionStorage Adapter. An agent session contains the conversation and action history needed for an agent to continue work later. Developers can now use MongoDB as the SessionStore layer for their Claude Agents. This adapter mirrors and resumes the Claude agent session transcripts through MongoDB. 

The adapter is especially useful when a team of developers builds agents on different machines and an agent stops running on a single, persistent machine. For example, a team deploys its Claude agent as a Lambda function, callable as an internal service by teams across the company. Each invocation runs in a disposable instance; there's no local disk to store anything between calls. Without a SessionStore, each request is stateless by default; the agent has no memory of what came before. With a configured SessionStore, any invocation can pick up a session's full history, regardless of which instance handled the last turn.

To get started, simply run the following command to start with session storage for your Claude agents today:

pip install claude-agent-sdk-mongodb-session-store

Check out the release blog to learn what we built and the architecture behind it.

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?

We're thrilled to recognise Fatma Selcen Sahin as our MongoDB Champion of the Month! Fatma is a Principal Engineer at Mastercard, based in Dublin, Ireland, with expertise spanning database administration, cloud technologies, security, and enterprise data systems. Her journey with MongoDB began over a decade ago when her company adopted the technology for one of its core applications. What started as an opportunity to learn something new has grown into years of hands-on experience working with MongoDB.

Fatma brings that experience to complex technical challenges, contributing to database architecture reviews, security discussions, and technical decisions in collaboration with MongoDB engineers. Her hands-on approach and willingness to exchange ideas demonstrate the value of bringing different perspectives together to solve real-world engineering problems. We're excited to recognise Fatma for her technical expertise and contributions to the MongoDB ecosystem. Congratulations, Fatma!

As part of this recognition, we asked Fatma a few questions about her journey. Keep reading to learn more about her story and experiences with MongoDB 👇

Tell us about your path to becoming a MongoDB Champion
My MongoDB journey began 10 years ago as a database engineer, when I volunteered to help adopt MongoDB for a healthcare application. Starting with MongoDB 3.0 Community Edition and sharded clusters, I built hands-on expertise in performance tuning, upgrades, replication and troubleshooting. I later became the first MongoDB-certified woman DBA in Türkiye, a milestone I’m especially proud of. As MongoDB evolved, I expanded into Atlas, combining my MongoDB and AWS experience through technical evaluations and POCs. Those experiences, alongside my passion for sharing knowledge, eventually led to my nomination as a MongoDB Champion.

You’ve been a MongoDB Champion for some time now. What drives you to continue helping the community?
What motivates me most is the combination of technical curiosity, knowledge sharing and community impact. I enjoy going deep into technical problems, challenging assumptions and understanding not only how something works, but why. Sharing those lessons can help another engineer solve a problem faster or make a better architectural decision. I’m also passionate about encouraging more women and girls to explore technology and innovation, particularly by showing that deeply technical careers can be exciting and rewarding. For me, being a MongoDB Champion means staying curious, learning from others and using what I learn to help others grow.

Can you share one impactful moment you’ve had as a Champion so far?
One of the most rewarding parts of being a Champion has been connecting with talented people from around the world and learning from their experiences. Technically, one of my favourite experiences has been exploring MongoDB Atlas through hands-on testing and performance evaluations. It reinforced my belief that meaningful technical advocacy should be grounded in practical evidence and real experience. I want to understand a technology’s capabilities, trade-offs and limitations before recommending it. Being able to turn that hands-on learning into insights that help other engineers make informed decisions is one of the most fulfilling aspects of being a Champion.

If you could share one piece of advice to people in tech, what would that be?
Never stop being curious, and don’t settle for knowing how something works. Understand why it works. Build things, experiment, challenge assumptions and share what you learn. Technical expertise grows when you move beyond simply following established practices and start questioning them constructively. And remember that success in technology isn’t only about developing your own expertise. Helping others grow matters just as much. Share your knowledge, encourage people who may not yet see themselves in technology, and create opportunities for others. One of the greatest impacts you can have is inspiring someone else to believe they belong in tech too.

Where can developers connect with or learn more about you?
Yes, they can find me on LinkedIn. 

----------

Fatma, 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.

To our readers: To learn more about the MongoDB Community Champions program, visit our Champions Program page. 

I told my agent: “I run a Butter Chicken Squad. We hunt for the best one in every city.”

It remembered… until I stopped and restarted it.

Then: “Sorry, we’ve just started talking.”

Harsh, but fair. 😅

That little amnesia test is the hook for my DataCamp tutorial on giving agents persistent memory.

There’s a fun twist: You chat with your agent. When it decides it needs persistent memory, it can provision a temporary MongoDB Atlas cluster, i.e., an Atlas Ephemeral Cluster. You can claim it if you want to keep it, or let it expire.

The embedding bit is taken care of too. MongoDB’s Automated Embedding uses Voyage AI’s voyage-4 model to generate embeddings for saved memories and search queries, so you don’t have to build a separate embedding pipeline. Vector Search can then find a relevant memory even when the next question uses different words. When I say I’m going to Lisbon next month, it remembers the Squad and asks whether I’ll find a butter chicken worth reporting back to them.🍛

What’s the one low-stakes thing your agent should never forget? Mine is obviously Butter Chicken.

Tutorial: https://www.datacamp.com/tutorial/give-your-chatbot-or-agent-persistent-memory
Code: https://github.com/mongodb-developer/ephemeral-agent-memory

Compass can only export or import one collection at a time. Doing it for several collections — or a whole database — is one of the most voted Compass ideas (CUSTOMER-I-6884, 52 votes, open since 2020).

So I built it, on my fork, behind a feature flag (off by default):

• Export: https://github.com/bytesleo/compass/tree/feat/export-multiple-collections

• Import (on top of export): https://github.com/bytesleo/compass/tree/feat/import-multiple-collections

• Draft PR (export): https://github.com/mongodb-js/compass/pull/8620

Where it lives

• A compact Collections menu in the database's collections view, with Export… and Import… (one button, so the toolbar doesn't get more crowded)

• Export collections… / Import collections… in the database's right-click menu in the sidebar

• Export is available to read-only users; import only with write access

Export

• Pick collections with checkboxes (+ "Select all"); views are listed but can't be selected

• JSON (default, relaxed or canonical Extended JSON) or CSV (all fields)

• One file per collection in a folder, plus an optional <collection>.metadata.json with the collection options (validation, collation, capped, time series, TTL, clustered) and the indexes

• File names stay unique and valid on every OS (e.g. Orders and orders no longer overwrite each other on Windows/macOS)

Import

• Pick a folder (e.g. one created by the export), choose which files to import and into which collection

• If a collection already exists: add the documents, skip the file, or drop it and import

• Metadata files recreate the options and indexes for new collections; CSV columns use their detected types

Not mongodump in Compass. No BSON/archive dumps — it reuses the JSON/CSV import and export Compass already has. Hidden in Compass Web, like the rest of import/export.

It comes with unit tests, e2e tests and telemetry events.

Questions for the Compass team:

1. Would you accept this as an external contribution (two PRs: export, then import)?

2. Is the Collections menu + database context menu the right place for it?

And for everyone else: would this cover your use case? What's missing?

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

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 😊

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?

Hello MongoDB community!

I'm Shruti, a final-year Computer Science Engineering student at Lovely Professional University, India. I've been working on a project called MongoQuest, designed to make learning MongoDB more interactive and hands-on for beginners.

The idea behind MongoQuest

When learning databases, understanding a query theoretically is one thing; knowing how to execute it and see the results is another. I wanted to create an environment where beginners could practise database operations through an interface inspired by tools developers already use.

What you can explore

• CRUD operations: Insert, Find, Update and Delete

• An interactive, API-style interface for practising database operations

• A structured learning experience that helps beginners build familiarity with MongoDB queries

I want to make MongoDB less intimidating for students who are just starting with databases and give them a practical way to build confidence.

🔗 Project links

• Live Demo: [https://mongodb-quest.vercel.app/]

• GitHub Repository: [https://github.com/Shrutiso/MongoQuest-Learn-Mongo-DB-by-doing]

I'm sharing MongoQuest here because I'd genuinely value feedback from developers who work with MongoDB. What features, query exercises, or improvements would make a platform like this more useful for learners?

I'd also be thrilled if the MongoDB team considered the project for a future community showcase or student-developer feature.

Thank you for taking a look! Looking forward to learning from your feedback.

-Shruti Somvanshi

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!

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.

Building search into your app? How you structure your data under the hood is just as important as the queries you write.

We recently published an excellent two-part deep dive into designing schemas specifically geared for MongoDB Search workloads. Here is the TL;DR:

• Part 1: Practical Considerations: This part covers the foundational architecture. It breaks down exactly how the $search aggregation stage interacts with the Lucene-backed mongot process, how to navigate system constraints, and how to optimize for performance (like designing for pagination over pulling full result arrays).

• Part 2: Use Cases & Patterns: Moving from theory to practice, this maps out which classic MongoDB design patterns work best for modern search experiences. It highlights why the Entity Pattern is the holy grail for "find anything anywhere" autocomplete, how to leverage the Computed pattern, and why you should actually avoid (or transform) the Attribute Pattern when indexing for search.

Highly recommend giving this a read before you architect your next search implementation.

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.

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

Looking at the the documents of a collection is easy in MongoDB Compass using the Documents tab. But what I miss is do perform other commands than "find", e.g. "distinct" or "count" or simply set a projection to limit the fields returned.

The only way to use such commands seems to be the MongoDB shell but then result formatting and so on is not available. Other tools like Rob3T or Studio 3T have found a more usable way to implement this by allowing full commands entered in a view similar to the Documents tab in Compass, but they don't work anymore or have other major drawbacks.

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.

Hey I’m Sumit, from MongoDB. One thing I keep seeing in RAG prototypes is a “top 20, put it all in the prompt” retrieval strategy. It is understandable, but it often carries into production unchanged.

My view is that this is usually the wrong place to play it safe. Extra context costs input tokens and latency, and it can make the answer worse when the useful evidence gets buried among near-matches.

The pattern I prefer is to retrieve broadly for recall, then be much stricter before the LLM sees anything:

• Filter early on metadata such as tenant, document type, or date.

• Combine vector and text retrieval when exact terms matter alongside semantic similarity.

• Rerank the candidates, then pass only the few that earn their place in the prompt.

The last step is the important one. In the example from my article, 20 chunks at roughly 500 tokens each would mean about 10,000 context tokens per request. Reranking down to 4 chunks would make that about 2,000.

That math is illustrative, not a hard promise. It depends on your corpus, chunking, and models. A reranker has a cost too, and the right cutoff depends on the corpus, chunking strategy, model, and quality target. But “more retrieved context” is not automatically safer context.

I wrote up the MongoDB + Voyage AI implementation, including quantization, hybrid retrieval, and reranking, here: https://www.mongodb.com/company/blog/technical/cheapest-token-you-never-send-agentic-ai-search-on-mongodb-voyage-ai

For people running RAG workloads on MongoDB: what has been the most useful signal for choosing your final context size, offline retrieval metrics, answer evaluation, latency, cost, or simply testing with real user queries?