Teach & Learn: Professor Margaret Menzin, Simmons University

Thalita Carrico
June 23, 2025

MongoDB’s Teach & Learn blog series interviews students and educators worldwide who are using MongoDB to enhance their classrooms. These stories highlight how MongoDB’s platform and resources are revolutionizing education and preparing tech professionals.

The MongoDB for Educators program offers free resources and technology for creating interactive learning environments that connect theory and practice. Educators gain access to MongoDB Atlas credits, curriculum, certifications, and a global community.

Unlocking potential: Integrating MongoDB to enhance learning in the classroom

Professor Margaret Menzin is a dedicated educator at Simmons University, where she was instrumental in developing one of the first undergraduate data science majors in the United States. With a keen eye on industry trends, she revamped her database course to include NoSQL technologies like MongoDB, recognizing their growing importance in the professional world. Her approach blends practical skills with theoretical understanding, ensuring her students are well-prepared for real-world challenges.

Professor Menzin also fosters a vibrant student community around MongoDB technology, empowering students to use these skills in their academic projects and future careers. Her MongoDB insights on curriculum and student engagement offer valuable perspectives for educators adapting to the evolving tech landscape, as you’ll see in our interview.

1. Tell us about your educational and professional journey and what initially sparked your interest in databases and MongoDB.

At Simmons, we were one of the first US universities to offer an undergraduate major in data science, so we were very aware of the importance of NoSQL for handling big data. In 2017, I returned to teaching databases after a hiatus of about seven years—and when I looked at the textbooks, they hadn’t changed. But the world sure had. So, I checked the Stack Overflow survey of what professional developers were using and found that 25% of them were using MongoDB. With my colleague’s permission, I revised our course to be about one-third on NoSQL, and I had to develop my own materials. But my students adore using MongoDB.

2. What courses related to databases and MongoDB are you currently teaching?

I teach a one-semester database course that’s required for all students majoring in computer science, data science, and information technology/cybersecurity. I also teach a course in full-stack web development, and students learn how to access MongoDB from Node.js.

3. What motivated you to incorporate MongoDB into your curriculum?

I was motivated by what is happening in the real world, but as an instructor, I find that having students learn something else in addition to relational databases makes the discussions much livelier about atomicity, consistency, isolation, and durability (ACID) transactions and concurrency in relational database management systems (RDBMSs). Now, students see where ACID transactions are important and where they’re not. (Yes, I know that MongoDB supports ACID transactions.) Similarly, the design process is different for MongoDB and for entity-relationship design, and that highlights the strengths of each.

Figure 1. Professor Margaret Menzin's students at Simmons University.

Photo of one of Margaret Menzin's class of students.

4. You have successfully built an active student community around MongoDB on your campus. Can you share some insights into how you achieved this and the impact it’s had on students?

First, I tell students to put MongoDB on their curricula vitae because it gives them an edge. Second, students are so enthusiastic about MongoDB that they turn to it when they have to build projects for senior courses. I do require that students install the MongoDB Community Edition on their own computers, and—without any data to back this claim up—I think that makes it more likely that they will turn to it. And they do. This year, a group of four seniors built a complete software system for a nonprofit on our campus, and they chose to use MongoDB. (I was not the supervisor; they chose MongoDB because they liked it and thought it was the best choice.)

5. How do you design your course content to integrate MongoDB in a way that engages students and ensures practical learning experiences?

In my course, I give students a set of comma-separated values (CSVs) for the Northwinds example (a pretty standard project with files for customers, products, orders, line items, etc.), and they denormalize the data. That is, they embed the line-item documents into the orders documents and do some computations, then embed the orders documents into the customers’ documents. They timed various operations with and without indexes. One thing I have learned is to put the exam on MongoDB before the project, so everyone on the team is ready to contribute to the project. I have a file of the approximately 5,000 restaurants in New York City that I use for the exam.

6. How has MongoDB supported you in enhancing your teaching methodologies and upskilling your students?

First, my students make extensive use of the MongoDB documentation. Reading documentation is an important skill for students to learn, and MongoDB’s is excellent. Second, I have gone through all the MongoDB videos for teachers, and I especially use the ones on the design process. For the aggregation pipeline, we use the book Practical MongoDB Aggregations, linked to on your site, and the Mosh Hamedani videos on YouTube. And because I was one of the very early adopters among professors, I’ve had to develop a lot of my own materials, which I’ve shared.

Figure 2. Professor Margaret Menzin's students at Simmons University.

Another photo of some of professor Menzin's students at Simmons University.

7. Could you share a memorable experience or success story of a project from your time teaching MongoDB that stands out to you?

After the first year I taught MongoDB, I asked my colleagues for feedback, and they suggested that I see what other people were doing on the Association for Computing Machinery (ACM) Special Interest Group on Computer Science Education (SIGCSE) LISTSERV. The result was a panel called “NoSQL is No Problem” for SIGCSE 2020. And there was a curated bibliography for various NoSQL platforms.

8. How has your role as a MongoDB educator impacted your professional growth and the growth of the student community at your university?

As a faculty member, I am always trying to see what’s going to be important next and find out how to learn it. Students respond to that attitude. I also lean very heavily on small-group work and team projects in all my courses. Most of my database students are sophomores, and they don’t know each other well yet. So in any small-group work, I say, “Even if it’s your roommate, begin with ‘Hello, my name is…’” and they laugh, but it works. It happens that the database course (occurring fall of the sophomore year) is when we try to build a sense of cohesion among our majors. I also require my students to take out an ACM student membership so I can assign a variety of readings and videos, and that helps them build professional identities. And my students love the fact that this is cutting-edge and that they are moving away from textbooks. I’m sure that listing MongoDB among their skills on LinkedIn and elsewhere also helps them find internships.

9. What advice would you give to educators who are considering integrating MongoDB into their courses to ensure a successful and impactful learning experience for students?

Allow about 30% of a first database course for the MongoDB work. It takes me about one and a half to two weeks to get students to install and learn basic MongoDB, and then another week and a half for the project. After that, use MongoDB as a jumping-off point to circle back to topics like forms of consistency, the CAP Theorem, design trade-offs, design decisions for distributed databases, and the choice of a database model. Comparing and contrasting MongoDB with an RDBMS is a very powerful way to summarize many of the key concepts in a database course. Finally, spending the last week on these high-level issues, when all of the students’ other courses are rushing to finish their projects, will make students very grateful.

Apply to the MongoDB for Educators program and explore free resources for educators crafted by MongoDB experts to prepare learners with in-demand database skills and knowledge.

← Previous

Build AI Memory Systems with MongoDB Atlas, AWS and Claude

When working with conversational AI, most developers fall into a familiar trap: They treat memory as simple storage—write data in, read data out. But human memory doesn't work this way. Our brains actively evaluate information importance, strengthen connections through repetition, and let irrelevant details fade over time. This disconnect creates AI systems that either remember too much (overwhelming users with irrelevant details) or too little (forgetting critical context). The stakes are significant: Without sophisticated memory management, AI assistants can't provide truly personalized experiences, maintain consistent personalities, or build meaningful relationships with users. The application we're exploring represents a paradigm shift—treating AI memory not as a database problem but as a cognitive architecture challenge. This transforms AI memory from passive storage into an active, evolving knowledge network. A truly intelligent cognitive memory isn't one that never forgets, but one that forgets with intention and remembers with purpose. Imagine an AI assistant that doesn't just store information but builds a living, adaptive memory system that carefully evaluates, reinforces, and connects knowledge just like a human brain. This isn't science fiction—it's achievable today by combining MongoDB Atlas Vector Search with AWS Bedrock and Anthropic's Claude. You'll move from struggling with fragmented AI memory systems to building sophisticated knowledge networks that evolve organically, prioritize important information, and recall relevant context exactly when needed. The cognitive architecture of AI memory At its simplest, our memory system mimics three core aspects of human memory: Importance-weighted storage: Not all memories are equally valuable. Reinforcement through repetition: Important concepts strengthen over time. Contextual retrieval: Memories are recalled based on relevance to current context. This approach differs fundamentally from traditional conversation storage: table, th, td { border: 1px solid black; border-collapse: collapse; } th, td { padding: 5px; } Traditional conversation storage Cognitive memory architecture Flat history retention Hierarchical knowledge graph Equal weighting of all information Importance-based prioritization Keyword or vector-only search Hybrid semantic & keyword retrieval Fixed memory lifetime Dynamic reinforcement & decay Isolated conversation fragments Connected knowledge network The practical implication is an AI that "thinks" before remembering—evaluating what information to prioritize, how to connect it with existing knowledge, and when to let less important details fade. Let's build a minimum viable implementation of this cognitive memory architecture using MongoDB Atlas , AWS Bedrock, and Anthropic's Claude. Our focus will be on creating the fundamental components that make this system work. Service architecture The following service architecture defines the foundational components and their interactions that power the cognitive memory system. Figure 1. AI memory service architecture. Built on AWS infrastructure, this comprehensive architecture connects user interactions with sophisticated memory management processes. The User Interface (Client application) serves as the entry point where humans interact with the system, sending messages and receiving AI responses enriched with conversation summaries and relevant contextual memories. At the centre sits the AI Memory Service, the critical processing hub that coordinates information flow, processes messages, and manages memory operations across the entire system. MongoDB Atlas provides a scalable, secure, multi-cloud database foundation. The system processes data through the following key functions: Bedrock Titan Embeddings for converting text to vector representations. Memory Reinforcement for strengthening important information. Relevance-based Retrieval for finding contextually appropriate memories. Anthropic’s Claude LLM handles the importance assessment to evaluate long-term storage value, memory merging for efficient information organization, and conversation summary generation. This architecture ultimately enables AI systems to maintain contextual awareness across conversations, providing more natural, consistent, and personalized interactions over time. Database structure The database structure organizes information storage with specialized collections and indexes that enable efficient semantic retrieval and importance-based memory management. Figure 2. Example of a database structure. The database design strategically separates raw conversation data from processed memory nodes to optimize performance and functionality. The Conversations Collection maintains chronological records of all interactions, preserving the complete historical context, while the Memory Nodes Collection stores higher-level semantic information with importance ratings that facilitate cognitive prioritization. Vector Search Indexes enable efficient semantic similarity searches with O(log n) performance, allowing the system to rapidly identify contextually relevant information regardless of database size. To manage storage growth automatically, TTL(Time-To-Live) Indexes expire older conversations based on configurable retention policies. Finally, Importance and User ID indexes optimize retrieval patterns critical to the system's function, ensuring that high-priority information and user-specific context can be accessed with minimal latency. Memory node structure The Memory node structure defines the data schemas that combine content with cognitive metadata to enable human-like memory operations. Figure 3. The memory node structure. Each node includes an importance score that enables memory prioritization similar to human memory processes, allowing the system to focus on what matters most. The structure tracks access count, which facilitates reinforcement learning by recording how frequently memories are retrieved. A critical feature is the summary field, providing quick semantic access without processing the full content, significantly improving efficiency. Vector embeddings within each node enable powerful semantic search capabilities that mirror human associative thought, connecting related concepts across the knowledge base. Complementing this, the ConversationMessage structure preserves raw conversational context without interpretation, maintaining the original exchange integrity. Both structures incorporate vector embeddings as a unifying feature, enabling sophisticated semantic operations that allow the system to navigate information based on meaning rather than just keywords, creating a more human-like cognitive architecture. Memory creation process The memory creation process transforms conversational exchanges into structured memory nodes through a cognitive pipeline mimicking human memory formation by thoughtfully evaluating new information against existing knowledge, rather than indiscriminately storing everything. Figure 3. The memory creation process. Through repetition, memories are strengthened via reinforcement, similar to human cognitive processes. At its core, the LLM functions as an "importance evaluator" that assigns each memory a value on a 1-10 scale, reflecting how humans naturally prioritize information based on relevance, uniqueness, and utility. This importance rating directly affects a memory's persistence, recall probability, and survival during pruning operations. As the system evolves, memory merging simulates the human brain's ability to consolidate related concepts over time, while importance updating reflects how new discoveries change our perception of existing knowledge. The framework's pruning mechanism mirrors our natural forgetting of less significant information. Rather than simply accumulating data, this dynamic system creates an evolving memory architecture that continuously refines itself through processes remarkably similar to human cognition. Memory retrieval process The memory retrieval process leverages multiple search methodologies that optimize both recall and precision to find and contextualize relevant information across conversations and memory nodes. Figure 4. The memory retrieval process. When initiated, the system converts user queries into vector embeddings while simultaneously executing parallel operations to enhance performance. The core of this system is its hybrid search methodology that combines vector-based semantic understanding with traditional text-based keyword search, allowing it to capture both conceptual similarities and exact term matches. The process directly searches memory nodes and applies different weighting algorithms to combine scores from various search methods, producing a comprehensive relevance ranking. After identifying relevant memories, the system fetches surrounding conversation context to ensure retrieved information maintains appropriate background, followed by generating concise summaries that distill essential insights. A key innovation is the effective importance calculation that dynamically adjusts memory significance based on access patterns and other usage metrics. The final step involves building a comprehensive response package that integrates the original memories, their summaries, relevance scores, and contextual information, providing users with a complete understanding of retrieved information without requiring exhaustive reading of all content. This multi-faceted approach ensures that memory retrieval is both comprehensive and precisely tailored to user needs. Code execution flowchart The code execution flowchart provides a comprehensive mapping of how API requests navigate through the system architecture, illuminating the runtime path from initial client interaction to final response delivery. Figure 5. The code execution flowchart. When a request enters the system, it first encounters the FastAPI endpoint, which serves as the primary entry point for all client communications. From there, specialized API route handlers direct the request to appropriate processing functions based on its type and intent. During processing, the system creates and stores message objects in the database, ensuring a permanent record of all conversation interactions. For human-generated messages meeting specific significance criteria, a parallel memory creation branch activates, analyzing the content for long-term storage. This selective approach preserves only meaningful information while reducing storage overhead. The system then processes queries through embedding generation, transforming natural language into vector representations that enable semantic understanding. One of the most sophisticated aspects is the implementation of parallel search functions that simultaneously execute different retrieval strategies, dramatically improving response times while maintaining comprehensive result quality. These searches connect to MongoDB Atlas to perform complex database operations against the stored knowledge base. Retrieved information undergoes context enrichment and summary generation, where the AWS Bedrock (Anthropic’s Claude) LLM augments raw data with contextual understanding and concise overviews of relevant conversation history. Finally, the response combination module assembles diverse data components—semantic matches, text-based results, contextual information, and generated summaries—into a coherent, tailored response that addresses the original request. The system's behavior can be fine-tuned through configurable parameters that govern memory processing, AI model selection, database structure, and service operations, allowing for optimization without code modifications. Memory updating process The memory updating process dynamically adjusts memory importance through sophisticated reinforcement and decay mechanisms that mimic human cognitive functions. Figure 6. The memory updating process. When new information arrives, the system first retrieves all existing user memories from the database, then methodically calculates similarity scores between this new content and each stored memory. Memories exceeding a predetermined similarity threshold are identified as conceptually related and undergo importance reinforcement and access count incrementation, strengthening their position in the memory hierarchy. Simultaneously, unrelated memories experience gradual decay as their importance values diminish over time, creating a naturally evolving memory landscape. This balanced approach prevents memory saturation by ensuring that frequently accessed topics remain prominent while less relevant information gracefully fades. The system maintains a comprehensive usage history through access counts, which informs more effective importance calculations and provides valuable metadata for memory management. All these adjustments are persistently stored in MongoDB Atlas, ensuring continuity across user sessions and maintaining a dynamic memory ecosystem that evolves with each interaction. Client integration flow The following diagram illustrates the complete interaction sequence between client applications and the memory system, from message processing to memory retrieval. This flow encompasses two primary pathways: Message sending flow: When a client sends a message, it triggers a sophisticated processing chain where the API routes it to the Conversation Service, which generates embeddings via AWS Bedrock. After storing the message in MongoDB Atlas, the Memory Service evaluates it for potential memory creation, performing importance assessment and summary generation before creating or updating a memory node in the database. The flow culminates with a confirmation response returning to the client. Check out the code reference on Github . Memory retrieval flow: During retrieval, the client's request initiates parallel search operations where query embeddings are generated simultaneously across conversation history and memory nodes. These dual search paths—conversation search and memory node search—produce results that are intelligently combined and summarized to provide contextual understanding. The client ultimately receives a comprehensive memory package containing all relevant information. Check out the code reference on Github . Figure 7. The client integration flow. The architecture deliberately separates conversation storage from memory processing, with MongoDB Atlas serving as the central persistence layer. Each component maintains clear responsibilities and interfaces, ensuring that despite complex internal processing, clients receive unified, coherent responses. Action plan: Bringing your AI memory system to life To implement your own AI memory system: Start with the core components: MongoDB Atlas, AWS Bedrock, and Anthropic’s Claude. Focus on cognitive functions: Importance assessment, memory reinforcement, relevance-based retrieval, and memory merging Tune parameters iteratively: Start with the defaults provided, then adjust based on your application's needs. Measure the right metrics: Track uniqueness of memories, retrieval precision, and user satisfaction—not just storage efficiency. To evaluate your implementation, ask these questions: Does your system effectively prioritize truly important information? Can it recall relevant context without excessive prompting? Does it naturally form connections between related concepts? Can users perceive the system's improving memory over time? Real-world applications and insights Case Study: From repetitive Q&A to evolving knowledge A customer service AI using traditional approaches typically needs to relearn user preferences repeatedly. With our cognitive memory architecture: First interaction: User mentions they prefer email communication. The system stores this with moderate importance. Second interaction: User confirms email preference. The system reinforces this memory, increasing its importance. Future interactions: The system consistently recalls email preference without asking again, but might still verify after long periods due to natural decay. The result? A major reduction in repetitive questions, leading to a significantly better user experience. Benefits Applications implementing this approach achieved unexpected benefits: Emergent knowledge graphs: Over time, the system naturally forms conceptual clusters of related information. Insight mining: Analysis of high-importance memories across users reveals shared concerns and interests not obvious from raw conversation data. Reduced compute costs: Despite the sophisticated architecture, the selective nature of memory storage reduces overall embedding and storage costs compared to retaining full conversation histories. Limitations When implementing this system, teams typically face three key challenges: Configuration tuning: Finding the right balance of importance thresholds, decay rates, and reinforcement factors requires experimentation. Prompt engineering: Getting consistent, numeric importance ratings from LLMs requires careful prompt design. Our implementation uses clear constraints and numeric-only output requirements. Memory sizing: Determining the optimal memory depth per user depends on the application context. Too shallow and the AI seems forgetful; too deep and it becomes sluggish. Future directions The landscape for AI memory systems is evolving rapidly. Here are key developments on the horizon: Short-term developments Emotion-aware memory: Extending importance evaluation to include emotional salience, remembering experiences that evoke strong reactions. Temporal awareness: Adding time-based decay that varies by information type (factual vs. preferential). Multi-modal memory: Incorporating image and voice embeddings alongside text for unified memory systems. Long-term possibilities Self-supervised memory optimization: Systems that learn optimal importance ratings, decay rates, and memory structures based on user satisfaction. Causal memory networks: Moving beyond associative memory to create causal models of user intent and preferences. Privacy-preserving memory: Implementing differential privacy and selective forgetting capabilities to respect user privacy boundaries. This approach to AI memory is still evolving. The future of AI isn't just about more parameters or faster inference—it's about creating systems that learn and remember more like humans do. With the cognitive memory architecture we've explored, you're well on your way to building AI that remembers what matters. Transform your AI applications with cognitive memory capabilities today. Get started with MongoDB Atlas for free and implement vector search in minutes. For hands-on guidance, explore our GitHub repository containing complete implementation code and examples.

June 18, 2025

Next →

Build an AI-Ready Data Foundation with MongoDB Atlas on Azure

It’s time for a database reality check. While conversations around AI usually focus on its immense potential, these advancements are also bringing developers face to face with an immediate challenge: Their organizations’ data infrastructure isn’t ready for AI. Many developers now find themselves trying to build tomorrow’s applications on yesterday’s foundations. But what if your database could shift from bottleneck to breakthrough? Is your database holding you back? Traditional databases were built for structured data in a pre-AI world—they’re simply not designed to handle today’s need for flexible, real-time data processing. Rigid schemas force developers to spend time managing database structure instead of building features, while separate systems for operational data and analytics create costly delays and complexity. Your data architecture might be holding you back if: Your developers spend more time wrestling with data than innovating. AI implementation feels like forcing a square peg into a round hole. Real-time analytics are anything but real-time. Go from theory to practice: Examples of modern data architecture at work Now is the time to rethink your data foundation by moving from rigid to flexible schemas that adapt as applications evolve. Across industries, leading organizations are unifying operational and analytical structures to eliminate costly synchronization processes. Most importantly, they’re embracing databases that speak developers’ language. In the retail sector , business demands include dynamic pricing that responds to market conditions in real-time. Using MongoDB Atlas with Azure OpenAI from Microsoft Azure, retailers are implementing sophisticated pricing engines that analyze customer behavior and market conditions, enabling data-driven decisions at scale. In the healthcare sector , organizations can connect MongoDB Atlas to Microsoft Fabric for advanced imaging analysis and results management, streamlining the flow of critical diagnostic information while maintaining security and compliance. More specifically, when digital collaboration platform Mural faced a 1,700% surge in users, MongoDB Atlas on Azure handled its unstructured application data. The results aligned optimally with modern data principles: Mural’s small infrastructure team maintained performance during massive growth, while other engineers were able to focus on innovation rather than database management. As noted by Mural’s Director of DevOps, Guido Vilariño, this approach enabled Mural’s team to “build faster, ship faster, and ultimately provide more expeditious value to customers.” This is exactly what happens when your database becomes a catalyst rather than an obstacle. Shift from “database as storage” to “database as enabler” Modern databases do more than store information—they actively participate in application intelligence. When your database becomes a strategic asset rather than just a record-keeping necessity, development teams can focus on innovation instead of infrastructure management. What becomes possible when data and AI truly connect? Intelligent applications can combine operational data with Azure AI services. Vector search capabilities can enhance AI-driven features with contextual data. Applications can handle unpredictable workloads through automated scaling. Seamless integration occurs between data processing and AI model deployment. Take the path to a modern data architecture The deep integration between MongoDB Atlas and Microsoft’s Intelligent Data Platform eliminates complex middleware, so organizations can streamline their data architecture while maintaining enterprise-grade security. The platform unifies operational data, analytics, and AI capabilities—enabling developers to build modern applications without switching between multiple tools or managing separate systems. This unified approach means security and compliance aren’t bolt-on features—they’re core capabilities. From Microsoft Entra ID integration for access control to Azure Key Vault for data protection, the platform provides comprehensive security while simplifying the development experience. As your applications scale, the infrastructure scales with you, handling everything from routine workloads to unexpected traffic spikes without adding operational complexity. Make your first move Starting your modernization journey doesn’t require a complete infrastructure overhaul or the disruption of existing operations. You can follow a gradual migration path that prioritizes business continuity and addresses specific challenges. The key is having clear steps for moving from legacy to modern architecture. Make decisions that simplify rather than complicate: Choose platforms that reduce complexity rather than add to it. Focus on developer experience and productivity. Prioritize solutions that scale with your needs. For example, you can begin with a focused proof of concept that addresses a specific challenge—perhaps an AI feature that’s been difficult to implement or a data bottleneck that’s slowing development. Making small wins in these areas demonstrates value quickly and builds momentum for broader adoption. As you expand your implementation, focus on measurable results that matter to your organization. Tracking these metrics—whether they’re developer productivity, application performance, or new capabilities—helps justify further investment and refine your approach. Avoid these common pitfalls As you undertake your modernization journey, avoid these pitfalls: Attempting to modernize everything simultaneously: This often leads to project paralysis. Instead, prioritize applications based on business impact and technical feasibility. Creating new data silos: In your modernization efforts, the goal must be integration and simplification. Adding complexity: remember that while simplicity scales, complexity compounds. Each decision should move you toward a more streamlined architecture, not a more convoluted one. The path to a modern, AI-ready data architecture is an evolution, not a revolution. Each step builds on the last, creating a foundation that supports not just today’s applications but also tomorrow’s innovations. Take the next step: Ready to modernize your data architecture for AI? Explore these capabilities further by watching the webinar “ Enhance Developer Agility and AI-Readiness with MongoDB Atlas on Azure .” Then get started on your modernization journey! Visit the MongoDB AI Learning Hub to learn more about building AI applications with MongoDB.

July 8, 2025