Building Together: MongoDB Is Google Cloud’s Technology Partner of the Year for Data Management

Matt Asay
June 17, 2022

Few companies can credibly claim to understand and work with data as effectively as Google, so when Google Cloud announced this week that MongoDB is the Google Cloud Technology Partner of the Year for Data Management, the award felt particularly meaningful.

But if the honor was just a matter of two leaders in data management slapping each other on the back, it wouldn't be that interesting. No, what makes the award compelling is the customer success that Google Cloud and MongoDB have jointly enabled. We agree with Google Cloud's vision that "True transformation spans the entire business and enables every person to transform," and together have helped customers to achieve this.

Some customers elect to run MongoDB Atlas, our fully managed database service, on Google Cloud because of its broad footprint (Atlas is available in 29 Google Cloud regions), cost/performance benefits, seamless security and scalability, and the recently launched pay-as-you-go option that simplifies subscriptions and can reduce costs. Others have gone further, choosing to take advantage of combining the best services from both companies, like using Google Kubernetes Engine (GKE) or Google Cloud Run for their application tier and MongoDB for their data tier. And some choose Google Cloud so they can tie into Google services that are tightly integrated with MongoDB, including BigQuery, Datastream, and Dataproc.

A few examples that show the ambition and innovation MongoDB and Google Cloud customers are bringing to their products:

Precognitive combines device intelligence, advanced behavioral analytics, and a real-time decision engine to accurately detect and prevent fraud for online businesses. Using Google Cloud Bigtable as their data store for behavioral and device data, and MongoDB as the data store for everything else, Precognitive is able to capture and analyze vast amounts of data from around the world, in near real time, to combat fraud. Read our full story on how Precognitive uses MongoDB Atlas.

Forbes, the world's largest business media brand, reaches more than 140 million people worldwide every month across a number of online and offline channels. The company needed to innovate its way through the global COVID-19 pandemic and turned to MongoDB Atlas running on Google Cloud to enable dramatically better agility. Among other initiatives, the publishing giant married MongoDB's flexible data schema with Google Cloud’s machine learning services to deliver a trending story recommendation engine for journalists. Read our full story on Forbes’ migration to Atlas — and the successes of that move.

One of the things we love about working with Google Cloud is the company's pragmatic approach to solving customer problems. Customers tend to choose a predominant cloud vendor upon which to build the majority of their applications, and Google Cloud often serves this role. At Plaid, which helps retailers decipher the complexities of consumer behavior, the company chose to migrate its legacy databases to MongoDB Atlas running on Google Cloud, allowing it to tap into Google Kubernetes Engine, Google Cloud Engine (GCE), Cloud BigTable, and BigQuery. But Plaid also needed to ensure it could run across multiple clouds, which Google Cloud enables with its Anthos service. MongoDB and Google Cloud, working together, deliver that multi-cloud experience for customers. Read our case study on Plaid, MongoDB, and Google Cloud.

If you’re ready to experience the fruits of the MongoDB and Google Cloud partnership, take a look at MongoDB Atlas in the Google console. You can get started for free.

Read more stories about MongoDB and Google Cloud customers doing great things:

← Previous

Built With MongoDB: Overcoming Employee Burnout Through Pioneera

Everyone can feel burned out from time to time. Working late hours to meet that project deadline, checking your phone on the weekend for any missed Slack messages from coworkers, an endless stream of Zoom calls — workplace stress can add up quickly and does not leave much room for taking care of yourself. With so much on your plate at any given time, it can be hard to pick up on the warning signs of burnout. One Australian startup has made its mission to prevent employees from reaching burnout with software trained to pick up on those warning signs and alert you. The application, Indie , from Australian startup Pioneera , sends personalized notifications in real time, when employees need them the most. Similar to a spellchecker, Indie helps individuals, teams, and companies prevent burnout. Built With MongoDB spoke with our 2022 MongoDB Savvy Startup Innovation Award winner , Danielle Owen Whitford , who founded Pioneera in 2018. Whitford discussed how she came up with the idea, how the software works, and what the future of Pioneera holds. Built With MongoDB: What is Pioneera all about? Danielle Owen Whitford: Pioneera uses early warning indicators to help reduce workplace stress and prevent burnout in a confidential and safe way. And when we see those early warning signs, helping that person get the help they need in real time to reduce their stress, promote wellness, improve productivity — all that good stuff. Essentially we are trying to use technology to prevent mental health issues in the workplace, which are rising at an alarming rate. Where did the names Pioneera and Indie come from? Our mission is to pioneer a new era of work, and it just came out as Pioneera! As for the name Indie, it’s actually named after my daughter. Our first MVP had a different name, and we had some mixed responses to the name. I was part of SheStarts, an accelerator program in Australia, and I was talking to my fellow founders about some of the experiences I had with my daughter and how she courageously called me out on working too hard. They said, “Why don’t you call the bot Indie?” Customers and users loved it, so Indie bot was a keeper. What are some examples of common stress signals that Indie picks up? We assess language, linguistic markers, and behaviors as the three key areas. From a language point of view, we see that there are certain types of words that are used within a workplace context that are exhibitors of stress. For example, when we’re stressed in real life, we say that we’re stressed, but at work we’re more likely to say, “I feel stretched.” And that’s a word that we have built into our scoring system, which we developed with a psychologist. On the positive side, we look for words like achievement and win. We also look for behavior — how we act in the workplace, particularly around our communication systems, because that’s where Indie sits. What made you decide to start Pioneera? I burned myself out in 2016. I spent 20 years in big companies and had a whole range of senior roles, from running retail networks and call centers to large-scale transformation. It’s not like I was hidden away in the organization — I reported into the executive team and was very visible, so we all saw the signs. I loved what I did, but I didn’t see the warning signs. I left because I felt like I had no other options. In hindsight I know that I did, but at the time, I just couldn't see past where I was at. That is a classic sign of burnout. I took a bit of time off. I started looking at my former colleagues and my peers, and I realized this burnout phenomenon was happening everywhere. I used to see emails from my team that said, “Here we go again” and “I don’t want to do this anymore.” My first degree was in psychology and my second was a Masters in Communication, so I instinctively responded to that language. So if I saw it, I would call them up and ask what was going on. My teams didn’t burn out and they always delivered. But clearly nobody had seen that for me, and I missed all the signs myself, so I burned out. I thought, “Wouldn’t it be cool if we could automate that for everyone?” The naivete in me thought that if Microsoft created a spell-checker, surely it can’t be that hard to create a spell-checker for stress. We know the language is there — we’ve all gotten emails from people where we know they’re having a bad day. That’s what I set out to do, to take my 20 years of experience and turn that into how I could help prevent this burnout from happening. I wanted Indie to do for the world what I had done for my colleagues. Burnout happens at an individual level, but the impacts are pretty significant — not just for that person or their family, but also for the workplace and then for society in general. We’re seeing health care costs that are through the roof, and we’re going to see long-term impacts on the next generation in terms of the ability to educate. These serious social issues are something I knew I needed to turn my attention to. In terms of employees, can you explain who has access to what information? We’re obsessed with privacy and confidentiality, and it's built into every part of the product. Everything is done in a way that protects the confidentiality and privacy of the individual. We did a lot of user testing before we started building the product, and users said that they really love this and the fact that their company would buy this for them. So it contributed to an employer value proposition. But, and it is a big but, they did not want their boss to know that they were stressed, because they thought they’d miss out on a project or HR would contact them or something like that. So that feedback has become the core of everything we do. What does the future of Pioneera look like? We’ve really upped our game on patterns of behaviors that indicate action is needed and the tips we provide to encourage action. We have partnered with expert psychologists to deliver content that is evidence- and research-based and proven to work. We’ve revolutionized our user experience to build connection and trust from the first moment a user hears about Indie. We’re looking to scale internationally with our vision for everyone globally to have Indie’s personalized, real-time support. What have you enjoyed the most about building Pioneera? It feels like there’s real meaning to what we’re doing and we’re actually making a difference in people's lives. I’ll get a call from a customer who says they were headed toward burnout and Indie stopped them. Or a call from a team manager delighted that they acted on Indie’s recommendations and their team is thriving. That sort of thing is always delightful to hear. I feel like we’re doing something positive for the world. How has working with MongoDB enabled Pioneera to succeed? The way the database is set up and structured has enabled us to focus on the things that we need to focus on, because we know MongoDB has our back. We’re a technology company building innovative technology, and we need to deliver our product to the market in a scalable, reliable way. You can run the risk of building a great technology, but it’s not actually a product that solves a problem for customers because the product features aren’t delivering value. MongoDB does technology really well, and that’s what we use it for — to make sure we’re delivering great product features and value to the customer today and tomorrow. Learn more about using Pioneera to overcome employee burnout and find out more about our MongoDB for Startups program .

June 16, 2022
Next →

Retrieval Augmented Generation for Claim Processing: Combining MongoDB Atlas Vector Search and Large Language Models

Following up on our previous blog, AI, Vectors, and the Future of Claims Processing: Why Insurance Needs to Understand The Power of Vector Databases , we’ll pick up the conversation right where we left it. We discussed extensively how Atlas Vector Search can benefit the claim process in insurance and briefly covered Retrieval Augmented Generation (RAG) and Large Language Models (LLMs). MongoDB.local NYC Join us in person on May 2, 2024 for our keynote address, announcements, and technical sessions to help you build and deploy mission-critical applications at scale. Use Code Web50 for 50% off your ticket! Learn More One of the biggest challenges for claim adjusters is pulling and aggregating information from disparate systems and diverse data formats. PDFs of policy guidelines might be stored in a content-sharing platform, customer information locked in a legacy CRM, and claim-related pictures and voice reports in yet another tool. All of this data is not just fragmented across siloed sources and hard to find but also in formats that have been historically nearly impossible to index with traditional methods. Over the years, insurance companies have accumulated terabytes of unstructured data in their data stores but have failed to capitalize on the possibility of accessing and leveraging it to uncover business insights, deliver better customer experiences, and streamline operations. Some of our customers even admit they’re not fully aware of all the data in their archives. There’s a tremendous opportunity to leverage this unstructured data to benefit the insurer and its customers. Our image search post covered part of the solution to these challenges, opening the door to working more easily with unstructured data. RAG takes it a step further, integrating Atlas Vector Search and LLMs, thus allowing insurers to go beyond the limitations of baseline foundational models, making them context-aware by feeding them proprietary data. Figure 1 shows how the interaction works in practice: through a chat prompt, we can ask questions to the system, and the LLM returns answers to the user and shows what references it used to retrieve the information contained in the response. Great! We’ve got a nice UI, but how can we build an RAG application? Let’s open the hood and see what’s in it! Figure 1: UI of the claim adjuster RAG-powered chatbot Architecture and flow Before we start building our application, we need to ensure that our data is easily accessible and in one secure place. Operational Data Layers (ODLs) are the recommended pattern for wrangling data to create single views. This post walks the reader through the process of modernizing insurance data models with Relational Migrator, helping insurers migrate off legacy systems to create ODLs. Once the data is organized in our MongoDB collections and ready to be consumed, we can start architecting our solution. Building upon the schema developed in the image search post , we augment our documents by adding a few fields that will allow adjusters to ask more complex questions about the data and solve harder business challenges, such as resolving a claim in a fraction of the time with increased accuracy. Figure 2 shows the resulting document with two highlighted fields, “claimDescription” and its vector representation, “claimDescriptionEmbedding” . We can now create a Vector Search index on this array, a key step to facilitate retrieving the information fed to the LLM. Figure 2: document schema of the claim collection, the highlighted fields are used to retrieve the data that will be passed as context to the LLM Having prepared our data, building the RAG interaction is straightforward; refer to this GitHub repository for the implementation details. Here, we’ll just discuss the high-level architecture and the data flow, as shown in Figure 3 below: The user enters the prompt, a question in natural language. The prompt is vectorized and sent to Atlas Vector Search; similar documents are retrieved. The prompt and the retrieved documents are passed to the LLM as context. The LLM produces an answer to the user (in natural language), considering the context and the prompt. Figure 3: RAG architecture and interaction flow It is important to note how the semantics of the question are preserved throughout the different steps. The reference to “adverse weather” related accidents in the prompt is captured and passed to Atlas Vector Search, which surfaces claim documents whose claim description relates to similar concepts (e.g., rain) without needing to mention them explicitly. Finally, the LLM consumes the relevant documents to produce a context-aware question referencing rain, hail, and fire, as we’d expect based on the user's initial question. So what? To sum it all up, what’s the benefit of combining Atlas Vector Search and LLMs in a Claim Processing RAG application? Speed and accuracy: Having the data centrally organized and ready to be consumed by LLMs, adjusters can find all the necessary information in a fraction of the time. Flexibility: LLMs can answer a wide spectrum of questions, meaning applications require less upfront system design. There is no need to build custom APIs for each piece of information you’re trying to retrieve; just ask the LLM to do it for you. Natural interaction: Applications can be interrogated in plain English without programming skills or system training. Data accessibility: Insurers can finally leverage and explore unstructured data that was previously hard to access. Not just claim processing The same data model and architecture can serve additional personas and use cases within the organization: Customer Service: Operators can quickly pull customer data and answer complex questions without navigating different systems. For example, “Summarize this customer's past interactions,” “What coverages does this customer have?” or “What coverages can I recommend to this customer?” Customer self-service: Simplify your members’ experience by enabling them to ask questions themselves. For example, “My apartment is flooded. Am I covered?” or “How long do windshield repairs take on average?” Underwriting: Underwriters can quickly aggregate and summarize information, providing quotes in a fraction of the time. For example, “Summarize this customer claim history.” “I Am renewing a customer policy. What are the customer's current coverages? Pull everything related to the policy entity/customer. I need to get baseline info. Find relevant underwriting guidelines.” If you would like to discover more about Converged AI and Application Data Stores with MongoDB, take a look at the following resources: RAG for claim processing GitHub repository From Relational Databases to AI: An Insurance Data Modernization Journey Modernize your insurance data models with MongoDB and Relational Migrator

April 18, 2024