Stack Overflow Research of 100,000 Developers Finds MongoDB is the Most Wanted Database

Michael Lynn
March 13, 2018 | Updated: April 22, 2021
#Company#Developer

It’s well established that developers want to work with a database that offers flexibility, versatility, and ease of use. Scalability and reliability certainly don’t hurt either. For an increasing number of developers, MongoDB is the desired solution to meet all these requirements. And for the second year in a row, this has been validated by the opinions of those who matter most — developers themselves.

Today, we’re excited to announce that, for the second year in a row, MongoDB is the most wanted database in the Stack Overflow Developer Survey 2018, the world’s largest developer survey with over 100,000 respondents.

Steady Increases in Popularity

Since its debut, MongoDB’s popularity among developers has steadily increased. This popularity has been driven primarily by the platform’s ease of use and flexibility; more recently, the release of the fully managed database service MongoDB Atlas has made it easier than ever to run the database in any of the major cloud platforms.

MongoDB continues to innovate, listening and reacting to the demands of developers from small startups to the largest of enterprises. New and exciting features to the platform include change streams, which push real-time data updates to downstream applications, retryable writes, which enhance reliability without increasing complexity, and the announcement of multi-document ACID transactions, coming in version 4.0 later this year.

Why MongoDB?

MongoDB’s document model offers developers massive increases in productivity by allowing developers to store data in a way that is consistent with how they think and create applications. Additionally, MongoDB’s native replication and horizontal partitioning give developers the confidence and freedom to concentrate on differentiating code without having to be concerned about challenges associated with data locality, reliability and scalability. Lastly, MongoDB offers the freedom to run consistently all the way from local development environments to the largest mainframe deployments. The database can be deployed on-premises, in a hybrid cloud, or in any of the public clouds.

How can you benefit from this news?

Hiring managers seeking talented developers may do well to review some of the additional statistics included in today’s release. One interesting statistic can be found in the chart entitled “How Developers Assess Potential Jobs”. If you are a hiring manager and you’re looking to attract top talent, considering the most wanted database platform might be a way to enhance the attractiveness of your opportunities.

Javascript and Python developers reviewing the Stack Overflow report will be encouraged as these development environments continue to grow in popularity. Popularity of web application stacks like MEAN or MERN have provided Javascript developers with frameworks for building applications quickly.

Not using Javascript or Python? MongoDB offers full support for these and all popular development languages. Want to use Golang with MongoDB? A fully supported MongoDB Golang driver has reached Alpha stage in development, giving even more options to developers to build with the latest and most popular languages.

In summary

Developers are the new Kingmakers and their opinions are vitally important. The results of the Stack Overflow survey are an exciting validation of MongoDB’s efforts to build a resilient, flexible, and easy-to-use platform wanted by developers the world over.

Are you looking to learn more?

MongoDB University offers free courses for beginners, developers, database administrators, and operations personnel. Get online education about MongoDB Atlas, Compass and other products to help developers build great modern applications.

Want to build right away with MongoDB? Get started today with a 512 MB database managed by MongoDB Atlas here.

← Previous

Optimizing for Fast, Responsive Reads with Cross-Region Replication in MongoDB Atlas

MongoDB Atlas customers can enable cross-region replication for multi-region fault tolerance and fast, responsive reads. Improved availability guarantees can be achieved by distributing replica set members across multiple regions. These secondaries will participate in the automated election and failover process should the primary (or the cloud region containing the primary) go offline. Read-only replica set members allow customers to optimize for local reads (minimize read latency) across different geographic regions using a single MongoDB deployment. These replica set members will not participate in the election and failover process and can never be elected to a primary replica set member. In this post, we’ll dive a little deeper into optimizing for local reads using cross-region replication and walk you through the necessary configuration steps on an environment running on AWS. Primer on read preference Read preference determines how MongoDB clients route read operations to the members of a replica set. By default, an application directs its read operations to the replica set primary . By specifying the read preference, users can: Enable local reads for geographically distributed users. Users from California, for example, can read data from a replica located locally for a more responsive experience Allow read-only access to the database during failover scenarios A read replica is simply an instance of the database that provides the replicated data from the oplog; clients will not write to a read replica. With MongoDB Atlas, we can easily distribute read replicas across multiple cloud regions, allowing us to expand our application's data beyond the region containing our replica set primary in just a few clicks. To enable local reads and increase the read throughput to our application, we simply need to modify the read preference via the MongoDB drivers. Enabling read replicas in MongoDB Atlas We can enable read replicas for a new or existing MongoDB paid cluster in the Atlas UI. To begin, we can click on the cluster “configuration” button and then find the link named "Enable cross-region configuration options." When we click this, we’ll be presented with an option to select the type of cross-replication we want. We'll choose deploy read-only replicas : As you can see above, we have our preferred region (the region containing our replica set primary) set to AWS, us-east-1 (Virginia) with the default three nodes. We can add regions to our cluster configuration based on where we think other users of our application might be concentrated. In this case, we will add additional nodes in us-west-1 (Northern California) and eu-west-1 (Ireland), providing us with read replicas to serve local users. Note that all writes will still go to the primary in our preferred region, and reads from the secondaries in the regions we’ve added will be eventually consistent. We’ll click "Confirm and Deploy", which will deploy our multi-region cluster. Our default connection string will now include these read replicas. We can go to the "Connect" button and find our full connection string to access our cluster: When the deployment of the cluster completes, we will be ready to distribute our application's data reads across multiple regions using the MongoDB drivers. We can specifically configure readPreference within our connection string to send clients to the "closest replicas". For example, the Node native MongoDB Driver permits us to specify our preference: readPreference Specifies the replica set read preference for this connection. The read preference values are the following: primary primaryPreferred secondary secondaryPreferred nearest For our app, if we want to ensure the read preference in our connection string is set to the nearest MongoDB replica, we would configure it as follows: mongodb://admin: @cluster0-shard-00-00-bywqq.mongodb.net:27017,cluster0-shard-00-01-bywqq.mongodb.net:27017,cluster0-shard-00-02-bywqq.mongodb.net:27017,cluster0-shard-00-03-bywqq.mongodb.net:27017,cluster0-shard-00-04-bywqq.mongodb.net:27017/test?ssl=true&replicaSet=Cluster0-shard-0&authSource=admin?readPreference=nearest Security and Connectivity (on AWS) MongoDB Atlas allows us to peer our application server's VPC directly to our MongoDB Atlas VPC within the same region. This permits us to reduce the network exposure to the internet and allows us to use native AWS Security Groups or CIDR blocks. You can review how to configure VPC Peering here . A note on VPCs for cross-region nodes: At this time, MongoDB Atlas does not support VPC peering across regions. If you want to grant clients in one cloud region read or write access to database instances in another cloud region, you would need to permit the clients’ public IP addresses to access your database deployment via IP whitelisting . With cross-region replication and read-only replicas enabled, your application will now be capable of providing fast, responsive access to data from any number of regions. Get started today with a free 512 MB database managed by MongoDB Atlas here .

March 12, 2018
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