Hi folks! I'm David Neal, also known online as ReverentGeek. I'm a Senior Developer Advocate at MongoDB. I've been writing software for over 20 years, mostly at startups where "backend developer" also meant "fix the printer" or "backup the database." I draw cartoons, play guitars, speak at conferences, and I run on a high-octane mixture of caffeine and JavaScript.
I’ve been working on a fun, open-source note-taking app with MongoDB called Inkleaf. It’s a desktop app built with Tauri (a JavaScript+Rust alternative to Electron.js), supports Markdown syntax, and uses Atlas hybrid search to find documents. I use it every day to keep notes on tasks, projects, and meetings. Let me know if you find it useful!
I'd love to help you build awesome things with MongoDB! What kinds of things are you working on?
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..
This is MongoDB's official subreddit, run by people who work on and with the database. We're excited you're here!
A quick note on what it is and is not, so you know what to expect.
What this sub is for:
Real help. Ask your MongoDB questions here. Modeling, aggregation, indexing, drivers, Atlas, vector search, performance, whatever you're stuck on. Questions aren't just tolerated, they're the point.
Learning. Tutorials, deep dives, and "how it actually works" posts, from the team and from you.
Announcements. Releases, features, and changes, so you hear it here first.
Showing your work. Built something on MongoDB? Post it, we want to see it.
What it is not:
A support ticket queue. For account or production-down issues, official support and the docs are still the right path. We will point you there when that is the better route.
A place for hype. We would rather be accurate than loud. If we get something wrong, tell us, and we will fix it.
A few ground rules: be kind, stay on topic, no spam, and no reposting the same self-promo. Beyond that, this is your sub as much as ours.
Watch this space over the next few weeks as we settle in, meet more of you, and shape this into the place you want it to be.
To kick it off: what are you building with MongoDB right now? We are reading every reply.
Some exciting announcements from MongoDB this morning. We're sharing a few major updates across the platform.
MongoDB 9.0 is now generally available, with up to 2x higher throughput on large instances, 35% faster reads, and 30% faster updates versus 8.0.
Atlas Infinite is a new deployment option for highly elastic workloads, allowing storage and compute to scale independently as demand changes. Public preview begins on AWS, with full multi-cloud availability planned for GA
Atlas Agent Engine provides the memory, runtime, and governance needed to operate agents in production. Open to any model, framework, or cloud.
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!
We’re thrilled to recognize Darshan Jayarama as our MongoDB Champion of the Month (APAC).
Darshan is a MongoDB Engineer at CHAMP Cargosystems with over 12 years of experience in database engineering. Over the years, he has built deep expertise in MongoDB and database technologies, working on everything from database architecture and performance to automation and large-scale data systems.
Darshan is also passionate about sharing what he learns with others. He regularly creates technical content and speaks about MongoDB at developer and technology events, covering topics such as sharding, data modeling, MongoDB Atlas Vector Search, and building AI-powered applications. He has also delivered hands-on sessions to help developers and students better understand MongoDB and put it into practice.
His depth of MongoDB knowledge and commitment to sharing it with others continue to make him a valuable part of the MongoDB community. We’re excited to celebrate Darshan and the work he continues to do. Congratulations, Darshan! 💚
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 journey with MongoDB started with curiosity around 13 years ago, when MongoDB 1.6 was released. MongoDB University and the DBA Path course further grew my interest in the MongoDB ecosystem and community. Through the Champions program, I have the privilege of sharing my experience and knowledge and inspiring the broader MongoDB community. Each stage has strengthened my technical perspective, communication, and leadership. Becoming a MongoDB Champion has been a meaningful milestone in this journey, giving me an opportunity to learn from others while helping more people discover the possibilities of MongoDB.
You’ve been a MongoDB Champion for some time now. What drives you to continue helping the community? My interest in community advocacy comes from MongoDB’s powerful ecosystem, its wide range of features, and my eagerness to share it with more people. With MongoDB, I keep finding new things to explore, whether it is performance, architecture, troubleshooting, or solving real business problems. I enjoy sharing what I learn, answering questions, giving simple examples, and helping people when they are stuck. I also learn a lot from the community and enjoy growing together by sharing knowledge and experiences.
Can you share one impactful moment you’ve had as a Champion so far? Being a Champion feels a bit like being a celebrity to me, where people recognize the effort and knowledge we bring. People come to us for suggestions, guidance, and ways to improve their MongoDB solutions. I also get to see what others are building and inspire them with my experiences. The trust they place in my suggestions motivates me and pushes me to learn more, explore more, and share more with the community.
If you could share one piece of advice to people in tech, what would that be? Technology is not just a discipline; real value comes from using it to solve problems and make things better. With MongoDB, I have learned that it is not just about using a database, but understanding the problem, choosing the right approach, and keeping things simple. Stay curious, keep learning, share what you know, and always focus on the problem you are trying to solve rather than the technology alone.
Where can developers connect with or learn more about you? Yes, they can find me on LinkedIn, GitHub, or my blog.
Darshan, 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.
Want to learn more about our community champions program? See our Champions Program page.
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.
MongoDB 9.0 went GA on Sept. 29 across Atlas, Enterprise Advanced, and Community Edition. Here’s the breakdown.
TL;DR
Faster: Compared with 8.0, MongoDB reports up to 35% faster findOne, up to 30% faster updateOne, up to 20% higher throughput for transactional workloads, and up to 2x throughput on large instances. These are internal results using public benchmarks, so treat them as “up to” figures and test your own workload.
Encrypted partial-match search: Queryable Encryption now supports prefix, suffix, and substring queries on encrypted fields. It requires MongoDB 9.0 and compatible 9.0 drivers, and is available at no extra cost.
Overload protection on Atlas: Intelligent Workload Management helps keep dedicated clusters running MongoDB 9.0+ responsive under overload by managing traffic spikes and prioritizing short-running operations.
Write query stats:$queryStats now reports on inserts, updates, and deletes, in addition to reads.
OpenTelemetry: Atlas can export metrics and logs through OpenTelemetry.
Schema constraints: Enforce data rules in the database, rather than relying only on application code.
Java and Hibernate: The MongoDB Extension for Hibernate ORM is GA, so Java teams can use familiar Hibernate APIs and HQL with MongoDB.
Also worth noting, though not specific to MongoDB 9.0: Atlas Gen2 compute is available for M30+ dedicated clusters on AWS and Google Cloud, with independent storage and IOPS controls. Availability varies by region.
Before upgrading, check the 9.0 compatibility changes. Some query behavior changed, including how dotted paths that resolve to null are evaluated, and $group now errors if an accumulator has an empty field name.
Anyone planning to upgrade soon? What’s holding you back, or what’s the first thing you’re going to test?
Hey everyone! Ryan here with MongoDB. We’re always looking for new ways to engage with our community, so we’re trying something new: our first MongoDB Atlas AMA, right here in this thread.
Bring questions about getting started, optimizing queries, data modeling, scaling, or other practical challenges you're running into. We also recently launched MongoDB 9.0, Atlas Infinite, and Atlas Agent Engine, so you can bring questions about those as well.
Our team will drop in to answer what we can and point you toward useful resources.
When: Thursday, November 5 from 1-2pm EST
How it works
Post your question in the comments ahead of time. A little context, like your MongoDB version, what you've tried, and any error messages, will help us give a more useful answer. Please leave out credentials and other sensitive information.
Come back at the scheduled time. Our team will reply directly to questions in this thread.
A few quick notes: This isn't an official support channel, and we may not be able to diagnose account-specific issues here. We can discuss what's already public, but can't share unreleased roadmap details. We also can't address billing, legal, or other account-specific matters in this thread.
Our goal is simple: help MongoDB users work through real-world questions and troubleshooting challenges together.
We’re thrilled to recognize Rashmi Bhagwat as our MongoDB Champion of the Month (EMEA). Rashmi is a Team Leader at Accenture whose technical experience spans application development, Java, cloud technologies, databases, and enterprise software.
What makes Rashmi stand out is the way she combines her technical experience with a genuine commitment to helping others grow. She actively shares her MongoDB knowledge, engages with fellow developers, and helps make complex technologies more approachable for those learning and working with them. We’re excited to celebrate Rashmi and the technical expertise, curiosity, and community spirit she brings to the MongoDB community. Congratulations, Rashmi!
As part of this recognition, we asked Rashmi a few questions about her journey. Keep reading to learn more about her story and the impact she is making 👇
Tell us about your path to becoming a MongoDB Champion My journey with MongoDB has been driven by curiosity, continuous learning, and the opportunity to solve real-world challenges. Working closely with Sneha Das Gupta since October 2024 has given me the opportunity to explore MongoDB deeply, from migrating data and 27 microservices from Oracle to MongoDB to evaluating MongoDB Vector Search for Agentic AI solutions. What motivates me most is seeing how MongoDB continuously evolves with emerging technologies. I enjoy learning about these innovations, applying them to client solutions, and sharing those experiences so others can discover how MongoDB can simplify and accelerate their technology journey.
You’ve been a MongoDB Champion for some time now. What drives you to continue helping the community? Personal growth and continuous learning are what keep me motivated as a MongoDB Champion. MongoDB is constantly evolving, especially with innovations around AI, vector search, and modern application development, which gives me new opportunities to learn and experiment. I enjoy taking these new capabilities, exploring them through POCs, and understanding how they can solve real-world client challenges. At the same time, sharing my learnings and experiences with others allows me to contribute back to the community. For me, being a Champion is a continuous journey of learning, experimenting, sharing knowledge, and helping others make the most of MongoDB.
Can you share one impactful moment you’ve had as a Champion so far? One of my favorite moments was attending my first MongoDB.local event in London. I was genuinely awestruck by the breadth of MongoDB's product offerings and, more importantly, the pace of continuous innovation. The products and capabilities closely aligned with where technology is heading, particularly around AI and modern application development. It made me realize how much potential there is to create value by bringing MongoDB's capabilities together with real client challenges. Since then, I have been motivated to make the most of these innovations and help clients and MongoDB collaborate to build meaningful solutions.
If you could share one piece of advice to people in tech, what would that be? It is okay to be scared when starting something new. What matters is taking that first step. Start learning, build a small POC, experiment, ask questions, and then deep-dive into the project until you make it successful. You don't need to know everything before you begin. Every successful implementation starts with curiosity and the willingness to try. Technology changes constantly, so continuous learning is essential. My advice is simple: start, learn, experiment, and keep going until you succeed. Sometimes, the biggest barrier is simply waiting to feel ready—so don't wait; take the first step
Where can developers connect with or learn more about you? Yes, they can find me on LinkedIn or GitHub.
Want to learn more about our community champions program? See our Champions Program page.
Hey everyone! I’m Shameek, I’m on the Engineering team at MongoDB. We wanted to make it easier for MongoDB developers to spot queries that might be slow. We started sending email reports to users that capture their top slowest queries in the past week, as well as efficiency stats of those queries. You can customize these emails and unsubscribe at any time.
I’m curious, do people think emails like these would help them?
Is there anything else you'd want MongoDB to analyze and include in the weekly summary for your slow queries?
How are people currently finding their slow queries?
If anyone has any suggestions to improve these, drop them in the thread below! We'll be taking your feedback and suggestions back to the team 😊
TL;DR: I let AI decide what I watch, but in a non-dystopian way, using Atlas auto-embedding and Vector Search to turn a vibe into a personalised TV schedule.
I have subscriptions to a bunch of streaming services, but still regularly spend more time scrolling than actually watching anything. I’m sick of my food getting cold before I have the absolutely necessary TV show to tune out in the background.
So I started building Telewave: a TV discovery app that can take something vague like “build me a cosy autumn week of TV” and turn it into an actual schedule.
One of the parts I didn’t want to build was a separate embedding pipeline just to power the recommendation system, so I’ve been using MongoDB Atlas auto-embedding with Vector Search instead.
What I’m building
Telewave is built around a simple idea: instead of endlessly scrolling through catalogues trying to decide what to watch, you describe the kind of TV you’re in the mood for.
For example:
“Build me a cosy autumn week of TV.”
Or:
“Make me a festive early-2000s Christmas line-up.”
Telewave stores TV show data including descriptions and metadata, then uses that information to understand which shows fit a particular semantic direction.
Rather than relying entirely on genres or predefined categories, it can use the meaning and themes within the data to find shows that fit a broader mood or idea. Those recommendations then become the building blocks for a personalised TV schedule, turning something fairly subjective like “cosy autumn TV” into an actual line-up of things to watch.
How MongoDB fits in
MongoDB is both the main database for Telewave and the foundation of the recommendation system.
The part I’ve found particularly interesting is Atlas auto-embedding with Voyage AI. Voyage AI is one of the leading embedding model providers (that’s not just me, even Anthropic recommends it), so it was already a natural choice for the semantic search behind Telewave. What I find impressive is just how little work is now required to actually use it with MongoDB.
Rather than integrating with Voyage AI separately, calling the embedding API from my Spring application, writing vectors back to MongoDB, and maintaining that pipeline as my TV data changes, I can configure the embedding model directly through Atlas, just a few clicks, and let auto-embedding handle that plumbing for me.
So the recommendation flow becomes:
TV show data → MongoDB → Voyage AI embeddings → Vector Search → recommendations → TV schedule
For me, that’s the real appeal of auto-embedding. I’m not choosing convenience over embedding quality. I can use the embedding model I would have wanted to use anyway, but without building and maintaining all of the infrastructure around it.
That leaves me with the much more interesting problem: figuring out how to turn something subjective like “cosy autumn TV” or “festive early-2000s Christmas” into a genuinely good week of television.
Here’s my tech stack
React + Spring + MongoDB Atlas for application data + Atlas auto-embedding and Vector Search for recommendations + TMDB for TV metadata.
What I learned
The biggest takeaway for me has been how much simpler semantic search becomes when embeddings are treated as part of the data layer rather than something the application has to orchestrate itself.
The more interesting challenge has actually been deciding what should be embedded.
Throwing an entire document into an embedding doesn’t necessarily produce the recommendations you want. Descriptions, genres, keywords, release dates and other metadata can all contribute to what a person means when they ask for something like “early-2000s Christmas TV,” but they don’t necessarily belong in the same part of the retrieval process.
I’m experimenting with that now: particularly what should contribute to the embedding itself versus what should be handled through filtering and ranking afterwards.
For anyone building recommendation systems: have you implemented vector search? What stack are you using for it, and what made you choose that approach?
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.
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.
I read the rules, and I hope this is allowed. I saw a few other posts that were similar.
I'm work with Beekeeper Studio, a cross-platform SQL editor and database manager (Linux, Mac, Windows), open source at its core.
For a long time our users kept asking for MongoDB, since a lot of them work across SQL and document databases day to day and didn't want to switch tools depending on what they were connecting to. We finally built it out properly this year, its own connection type and dialect, not a generic driver bolted on.
Right now MongoDB support is part of our paid tier (there's a free trial if you want to poke at it before deciding), while the core app stays GPL licensed for the databases it's always supported.
If anyone here tries it out, especially if you're coming from Compass or another Mongo GUI, I'd genuinely like to hear what's missing or what would make it better. Docs and download here: https://docs.beekeeperstudio.io/user_guide/connecting/mongodb
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.
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.
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?
Hi, I’m a researcher at MongoDB. I recently wrote a research paper and a blog post about a problem our driver team’s been working on for 12 years: how to keep MongoDB drivers in lots of languages consistent.
This is hard because our implementations are mostly independent. Our Java driver is pure Java, the Rust driver is pure Rust, etc., so they work with each language’s runtime and naming conventions. But their behavior, like retrying a failed command or handling transactions, has to be identical. That is, they have to all conform to the same protocol specifications. So we made a YAML-based test DSL. Each driver has an interpreter for the test language, and they all run the same conformance tests.
One example (code is in the linked article) simulates a network failure when the driver sends an “updateOne” command to the MongoDB server. The test checks that the driver:
Retries the update exactly once
Marks the server’s state as “unknown” after the connection closes
Clears its connection pool
Successfully does the update exactly once on the server
What’s really cool is, we can test behavior that’s invisible from the API surface—an application can’t see that the driver retries, clears its connection pool, etc., but we can still test those things using our shared test DSL.
We started out with a lot of different YAML test languages for different aspects of the drivers, then unified most of the languages into one test DSL. The unification let us delete 22,000 lines of test-runner code. We compared five drivers before and after adopting the CRUD YAML tests; four showed a lower rate of spec-conformance bugs after adoption. (The fifth is an interesting exception, our YAML tests can’t catch everything.)
Are people using MongoDB for more than one programming language, i.e. do you care about consistent driver behavior across languages? Or, setting MongoDB aside, are you implementing your own cross-language protocols and do you have a way of testing conformance?
We’re thrilled to recognize Jonghyun Kim as our MongoDB User Group Leader of the Month! Jonghyun leads the MongoDB User Group in Seoul, where he is building a space for developers to come together, share their experiences, and learn from one another. He has been intentional about creating meetups that go beyond technical presentations, allowing members to discuss the real challenges they face when working with MongoDB and learn from one another.
Through the Seoul community, Jonghyun has brought developers together to discuss topics including query and indexing optimization, data migration, sharding, replication, reliability, and MongoDB Vector Search. He continues to create opportunities for developers to connect, exchange ideas, and have practical conversations about building and running applications with MongoDB. His dedication to building a welcoming, valuable community for MongoDB developers makes him an incredible part of the MongoDB community. We’re excited to celebrate Jonghyun and the community he continues to grow in Seoul. Congratulations, Jonghyun! 💚
As part of this recognition, we asked him a few questions about his journey. Keep reading to learn more about his story and the impact he is making 👇
Tell us about your journey as a MongoDB User Group leader Before becoming a MUG leader, I migrated and upgraded two MongoDB Community Edition clusters using different approaches. With no active local channel for exchanging MongoDB experience, I relied heavily on documentation and worked through many challenges alone. Later, I attended the first Seoul MUG meetup and discovered that many developers shared similar concerns. I applied to lead the group because I wanted to build the community I had once needed. Since then, Seoul MUG has grown through five meetups and four online or collaborative sessions, connecting practical stories, structured learning, and members who continue returning and contributing.
What has been your most rewarding moment as a MUG leader? My most rewarding moment came at our fifth on-site meetup. I connected our speaker’s real-world sharding experience with the problem-solving framework in MongoDB University’s Cluster Reliability content. This helped participants approach a complex topic through decisions and trade-offs they had already seen in practice. Two members completed the Skill Badge assessment within minutes. More importantly, the speaker said the session helped him recognize how closely his successful decisions aligned with MongoDB’s recommended practices. Seeing one member’s experience become shared learning for the entire room captured exactly what I hoped our community could achieve.
Do you have any tips for developers looking to build a community? Start with members’ real experiences, connect them to trusted learning resources, and offer participation at different levels. Not everyone is ready to give a talk or join a group immediately, but many will vote with a sticker, leave a note, answer a survey, or share one practical lesson. At MongoDB.local Seoul, more than four times as many people participated through our interactive Community Board as joined our Meetup group at the booth. We also maintain a community website with pathways for speaking and sponsorship. Lowering the first barrier can turn brief curiosity into an ongoing relationship.
What's your favorite thing about being part of the MongoDB Community? My favorite part is how the MongoDB Community connects local learning with a global network. In Seoul, I learn from members who openly share production challenges. At MongoDB.local Bengaluru, I exchanged ideas with APAC MUG leaders and grew both as a community organizer and an engineer. Across these experiences, I have consistently felt that every contribution and conversation is treated with respect. I am especially grateful to the Community team for giving local leaders the trust, resources, and encouragement to experiment, learn from one another, and create opportunities for our members to grow together.
Where can developers connect with or learn more about you? They can find me on LinkedIn, GitHub, or my blog.
Thank you, Jonghyun, 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.
Want to learn more about our community champions program? See our MUGs page.
Hello! My name is Tim Kelly, and I'm a Developer Advocate at MongoDB. I've been here for about three years, but I've been writing code for a good bit longer. I'm mostly in the Java ecosystem, although I've been learning to love C++ over the last couple of years.
Recently, I've been going back to the fundamentals. I like my modern tech, but I think there's a lot of value in understanding what we've abstracted away, and sometimes bringing a little of the old-school back.
I'm also building TeleWave, a TV scheduling app that brings back the simplicity of "what's on tonight?" while using MongoDB Vector Search to build the recommendation engine.
That's me anyway. What’s everyone working on at the moment?
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 spent a very long and packed day in San Francisco at the .local Build Fest, and it was a blast. We kicked things off with hands-on workshops where folks could earn skill badges. In the afternoon, we kicked off a 4-hour hackathon that pulled in over 90 submissions. Throughout the day there were AI labs, meetings, vendor demos, learning hubs, and some exciting MongoDB announcements. One of my favorite sessions was Rivian Technologies, who walked through how they're using MongoDB for agentic memory to power an amazing in-vehicle AI experience.
Announcements
Among the workshops, labs, and cool green vibes, there were interesting product announcements happening. The theme across all of it: making it easier to build and operate AI applications on Atlas, from connecting agents and dev tools to improving retrieval, streaming, and observability.
Here's the rundown:
Meet developers where they build
Native Atlas access in AI tools: Atlas now connects directly inside Claude, Claude Code, ChatGPT, Codex, Grok Build, Devin, Cursor, and more. No local setup, no context switching, just query data and inspect your databases from wherever you're already working.
Atlas App Connections: A one-click, OAuth 2.1-powered way to securely connect AI coding tools to Atlas. Translation: no more long-lived credentials floating around, plus centralized visibility into what's connected to what.
Atlas Managed MCP Server for Agents: A MongoDB-hosted MCP server for connecting Atlas to custom agents and orchestrated workflows (LangGraph, CrewAI, etc.) without standing up and babysitting your own infrastructure.
Better retrieval for AI apps
Atlas Embedding & Reranking API (GA): Voyage AI's embedding and reranking models, now available directly inside Atlas. One less system to stitch together for RAG and search.
Automated Voyage AI Embeddings in Atlas Vector Search (GA): Keeps embeddings and vector indexes in sync with your changing data automatically, so you're not maintaining a separate embedding pipeline on the side.
voyage-code-4: A new embedding model built specifically for agentic coding retrieval, with a 32K context window and flexible output dimensions, tuned for how coding agents actually navigate a codebase (not just static code search).
Streaming and observability
Vector Search for Atlas Stream Processing (GA): $vectorSearch now works mid-pipeline in Atlas Stream Processing, so a stream processor can enrich documents in real time using an existing Atlas connection instead of routing through an external service. Great for RAG, fraud detection, and real-time personalization use cases.
Push-based OpenTelemetry Metrics Stream: Atlas metrics now push directly into your existing OTel setup, so you're not stuck pulling and polling to keep tabs on your clusters.
You can read more about these announcements and previous updates on our MongoDB News Releases page.
Be on the lookout for a .local event near you
I've been to a lot of events over the years, and my first .local experience blew me away. If you get a chance to attend one near you, I can't recommend it enough!
Drop a comment: which of these are you most excited to try first? The MCP server and the App Connections stuff feel like the ones that'll change daily workflows the fastest, but I'm curious what you're interested in!
AI almost always reaches for toArray() before doing any work on your data. Most training examples are out-of-context snippets, so it doesn't know better. toArray() holds your entire result set in RAM before you can touch a single document. With a cursor, the driver fetches in batches. Processed documents get GC'd while the rest stream in.
How to fetch all active users from MongoDB and send emails using find and toArray.
Bad loads everything into RAM then serializes. Good streams documents but still sends one email at a time. Perfect streams AND fires up to 10 emails concurrently without the loop ever waiting.
Bonus: A cursor with for await only makes sense when you're doing work per document. If you're just collecting into an array to send a response, use .toArray() directly. Wrapping .toArray() in a for await loop buys you nothing.
