MongoDB Empowers ISVs to Drive SaaS Innovation in India

MongoDB
February 11, 2025

Independent Software Vendors (ISVs) play a pivotal role in the Indian economy. Indeed, the Indian software market is expected to experience an annual growth rate of 10.40%, resulting in a market volume of $15.89bn by 2029.1

By developing specialized software solutions and digital products that can be bought 'off the shelf', ISVs empower Indian organizations to innovate, improve efficiency, and remain competitive.

Many established enterprises in India choose a 'buy' rather than 'build' strategy when it comes to creating modern software applications. This is particularly true when it comes to cutting-edge AI use cases.

MongoDB works closely with Indian ISVs across industries, providing them with a multi-cloud data platform and highly flexible, scalable technologies to build operational and efficient software solutions.

For example, Intellect AI, a business unit of Intellect Design Arena, has used MongoDB Atlas to drive a number of innovative use cases in the banking, financial services, and insurance industries.

Intellect AI chose MongoDB for its flexibility coupled with its ability to meet complex enterprise requirements such as scale, resilience, and security compliance. And Ambee, a climate tech startup, is using MongoDB Atlas’ flexible document model to support its AI and ML models.

Here are three more examples of ISV customers who are enabling, powering, and growing their SaaS solutions with MongoDB Atlas.

MongoDB enhancing Contentstack's content delivery capabilities

Contentstack is a leading provider of composable digital experience solutions, and specializes in headless content management systems (CMS). Headless CMS is a backend-only web content management system that acts primarily as a content repository.

“Our headless CMS allows our customers to bring all forms of content to the table, and we host the content for them,” said Suryanarayanan Ramamurthy, Head of Data Science at Contentstack, while speaking at MongoDB.local 2024.

A great challenge in the CMS industry is the ability to provide customers with content that remains factually correct, brand-aligned, and tailored to the customer’s identity. Contentstack created an innovative, AI-based product—Brand Kit—that does exactly that, built on MongoDB Atlas.

“Our product Brand Kit, which launched in June 2024, overcomes factual incorrectness. The AI capabilities the platform offers help our customers create customized and context-specific content that meets their brand guidelines and needs,” said Ramamurthy.

MongoDB Atlas Vector Search enables Contentstack to transform content and bring contextual relevance to retrievals. This helps reduce errors caused by large language model hallucinations, allowing the retrieval-augmented generation (RAG) application to deliver better results to users.

AppViewX: unlocking scale for a growing cybersecurity SaaS pioneer

AppViewX delivers a platform for organizations to manage a range of cybersecurity capabilities, such as certificate lifecycle management and public key infrastructure. The company ensures end-to-end security compliance and data integrity for large enterprises across industries like banking, healthcare, and automotive.

Speaking at MongoDB.local Bengaluru in 2024, Karthik Kannan, Vice President of Product Management at AppViewX, explained how AppViewX transitioned from an on-premise product to a SaaS platform in 2021. MongoDB Atlas powered this transition.

MongoDB Atlas's unique flexibility, scalability, and multi-cloud capabilities enabled AppViewX to easily manage fast-growing data sets, authentication, and encryption from its customers’ endpoints, device identities, workload identities, user identities, and more. Furthermore, MongoDB provides AppViewX with robust security guaranteeing critical data protection, and compliance.

“We've been really able to grow fast and at scale across different regions, gaining market share,” said Kannan.

“Our engineering team loves MongoDB,” added Kannan. “The support that we get from MongoDB allowed us to get into different regions, penetrate new markets to grow at scale, so this is a really important partnership that helped us get to where we are.”

Zluri Streamlines SaaS Management with MongoDB

Zluri provides a unified SaaS management platform that helps IT and security teams manage applications across the organization. The platform provides detailed insights into application usage, license optimization, security risks, and cost savings opportunities.

Zluri processes massive volumes of unstructured data—around 9 petabytes per month—from over 800 native integrations with platforms like single sign-on, human resources management systems, and Google Workspace. One of its challenges was to automate the discovery and data analysis across those platforms, as opposed to employing an exhaustive time and labour intensive manual approach.

MongoDB Atlas has allowed Zluri to ingest, normalize, process, and manage the high volume and complexity of data seamlessly across diverse sources.

“We wanted to connect with every single system that's currently available, get all that data, process all that data so that the system works on autopilot mode, so that you're not manually adding all that information,” said Chaithaniya Yambari, Zluri’s Co-Founder and Chief Technology Officer, when speaking at MongoDB.local Bengaluru in 2024.

As a fully managed database, MongoDB Atlas platform allows Zluri to eliminate maintenance overhead, so its team of engineers and developers can focus on innovation.

Zluri also utilizes MongoDB Atlas Search to perform real-time queries, filtering, and ranking of metadata. This eliminates the challenges of synchronizing separate search solutions with the database, ensuring IT managers get fast, accurate, and up-to-date results.

These are just a few examples of how MongoDB’s is working with ISVs to shape the future of India’s digital economy. As technology continues to evolve, the role of ISVs in fostering innovation and economic growth will become ever more integral. MongoDB is committed to providing ISVs with a robust, flexible, and scalable database that removes barriers to growth and the ability to innovate.

Visit our product page to learn more about MongoDB Atlas.

Learn more about MongoDB Atlas Search on our product details page.

Check out our Quick Start Guide to get started with MongoDB Atlas Vector Search today.

← Previous

Busting the Top Myths About MongoDB vs Relational Databases

I was talking with a friend of mine recently about deciding between databases for an upcoming project. I asked him his thoughts on MongoDB. He told me that he did not think it would work based on what he knew about it. The only issue was that everything he learned about MongoDB was from 2013. He had not kept up with over a decade of improvements and updates. From talking with other developers this seems to be a pretty common situation. A lot of developers got a first impression of MongoDB in 2012-2014 and made up their minds based on that. In this post, we will dive into some database history and look at how MongoDB compares to relational databases today. As a quick refresher, there are a number of types of databases, but we will be focusing on relational and NoSQL document databases since those are two of the most popular types in use today. Relational databases were introduced in the 1970s and store data in tables. While the term NoSQL was coined in 1998 by Carlo Strozzi, it took a few more years for NoSQL databases and their more flexible approach to storing data to really take off. In 2009 MongoDB launched with the idea of storing data in documents similar to JSON objects. When I am explaining the basic difference between relational and document databases to my family, I usually say one is like a spreadsheet and the other is like a Google Doc. I am still not sure how much my grandma understands about what my job is, but at least she knows the difference between database types now. OK, now that we have covered the basics, we will take a look at misconceptions that come up when comparing MongoDB to relational databases. Myth 1: MongoDB does not have a schema Schemata define the structure of data in a database. With relational databases, you typically design your schema based on normalizing your data. Normalizing means you split up your data into different tables so that you do not duplicate data. These defined schemata are great if you can anticipate all your future data needs and elegantly design them in advance. Updating these schemata to add new fields can add extra work and downtime for your application. Figure 1. A simple set of relational data split across 3 tables. With MongoDB, your schema is dependent on the needs of your application. This is a more flexible approach to schema design. Now even though there is flexibility, there are still best practices like the rule that “data that is accessed together should be stored together.” Here is an example of the relational data from above stored in MongoDB: { "first_name": "Paul", "surname": "Miller", "cell": "447557505611", "city": "London", "location": [45.123, 47.232], "profession": ["banking", "finance", "trader"], "cars": [ { "model": "Bentley", "year": 1973 }, { "model": "Rolls Royce", "year": 1965 } ] } You can see in this example that you are able to get all the data on “Paul Miller” without having to do JOINS on three different tables. You can do JOINS in MongoDB, but more on this later. With a flexible schema, developers are able to start building applications without having to design beforehand the definitive schema, and then constraining themselves to it. You can easily add new fields to your schema whenever the application requires it. If you want to have that more structured schema, you can use MongoDB’s schema validation feature. If you need your schema to evolve over time, you can also easily implement the schema versioning pattern. Ultimately I think this myth of MongoDB having no schema comes down to two things. First, it did not have schema validation in the early days (it was added in version 3.6 in 2017). The other reason comes from the flexibility developers have in creating their schema based on the needs of their applications. Freedom and flexibility does not mean not having a schema; it just means it is important to follow best practices to create an elegant schema that makes your application run optimally. Myth 2: MongoDB is not ACID compliant Databases need ways to make sure that operations and the resulting data are reliable even when errors or power failures occur. The main way they do this is by implementing four properties: atomicity, consistency, isolation, and durability, also known as ACID . MongoDB is ACID compliant. Every time that you perform any create, read, update, and delete operation on a single document, data integrity is preserved. MongoDB handles data one document at a time. Otherwise, it would not be a document database. It would be a chaotic, unpredictable database. Can you imagine lots of writers trying to overwrite the same document at the same time? I have been in some Google docs with 10+ writers all contributing at the same time, and it certainly does not feel ACID compliant. That covers single documents, but what happens with multidocument transactions? Multidocument transactions are used frequently in relational databases, since you often have to access multiple tables when doing things like updating a customer record. MongoDB guarantees multidocument ACID transactions from and to any location in your MongoDB cluster. It has supported this guarantee since version 4.0 back in 2018 . In fact, transactionality is one of MongoDB’s greatest strengths. Many financial services companies trust MongoDB transactions for core banking and trading use cases. The all-or-nothing guarantee of MongoDB multidocument transactions has got your back. Myth 3: MongoDB cannot make JOINS to handle relational data Earlier we showed how relational databases rely on data split across multiple tables for efficient schema design. To work with relational data, you often need to pull data from those tables and combine them using JOINS. MongoDB can do JOINS with the $lookup command. But the fact that you can do something does not mean you should. MongoDB data is modeled in a different manner than relational data. In MongoDB, data that is accessed together is stored together. With most of the data in a single document instead of spread across multiple tables, you would not need to do any JOINS since the data is already in the right place. This shift from the relational model to the document model is a big mindset shift, but once you experience the benefits, it is hard to go back. However, if you still need to do JOINS with MongoDB, the command $lookup is your best ally. You can even create a VIEW ( added in 2016 ) to join two collections. The myth that JOINS are not possible ultimately comes down to the basic difference between the relational and document models. Data accessed in tables and data accessed in documents require different approaches, but generally, even though you can do JOINS in MongoDB, you will not need to if you have designed the schema for your documents well. To learn more about MongoDB, head over to MongoDB University and take our free Intro to MongoDB course . Sign up for a free Atlas cluster today to see what MongoDB Atlas is capable of. Check out the full video to learn about the other 6 myths that we're debunking in this series.

February 10, 2025
Next →

Simplify Security At Scale with Resource Policies in MongoDB Atlas

Innovation is the gift that keeps on giving: industries that are more innovative have higher returns, and more innovative industries see higher rates of long-term growth 1 . No wonder organizations everywhere strive to innovate. But in the pursuit of innovation, organizations can struggle to balance the need for speed and agility with critical security and compliance requirements. Specifically, software developers need the freedom to rapidly provision resources and build applications. But manual approval processes, inconsistent configurations, and security errors can slow progress and create unnecessary risks. Friction that slows down employees and leads to insecure behavior is a significant driver of insider risk. Paul Furtado Vice President, Analyst, Gartner Enter resource policies , which are now available in public preview in MongoDB Atlas. This new feature balances rapid innovation with robust security and compliance. Resource policies allow organizations to enable developers with self-service access to Atlas resources while maintaining security through automated, organization-wide ‘guardrails’. What are resource policies? Resource policies help organizations enforce security and compliance standards across their entire Atlas environment. These policies act as guardrails by creating organization-wide rules that control how Atlas can be configured. Instead of targeting specific user groups, resource policies apply to all users in an organization, and focus on governing a particular resource. Consider this example: An organization subject to General Data Protection Regulation (GDPR) 2 requirements needs to ensure that all of their Atlas clusters run only on approved cloud providers in regions that comply with data residency and privacy regulations. Without resource policies, developers may inadvertently deploy clusters on any cloud provider. This risks non-compliance and potential fines of up to 20 million euros or 4% of global annual turnover according to article 83 of the GDPR. But, by using resource policies, the organization can mandate which cloud providers are permitted, ensuring that data resides only in approved environments. The policy is automatically applied to every project in the organization, preventing the creation of clusters on unauthorized cloud platforms. Thus compliance with GDPR is maintained. The following resource policies are now in public preview: Restrict cloud provider: Limit Atlas clusters to approved cloud providers (AWS, Azure, Google Cloud). Restrict cloud region: Restrict cluster deployments in approved cloud providers to specific regions. Block wildcard IP: Reduce security risk by disabling the use of 0.0.0.0/0 (or “wildcard”) IP address for cluster access. How resource policies enable secure self-service Atlas access Resource policies address the challenges organizations face when trying to balance developer agility with robust security and compliance. Without standardized controls, there is a risk that developers will configure Atlas clusters to deviate from corporate or external requirements. This invites security vulnerabilities and compliance gaps. Manual approval and provisioning processes for every new project creates delays. Concurrently, platform teams struggle to enforce consistent standards across an organization, increasing operational complexity and costs. With resource policies, security and compliance standards are automatically enforced across all Atlas projects. This eliminates manual approvals and reduces the risk of misconfigurations. Organizations can deliver self-service access to Atlas resources for their developers. This allows them to focus on building applications instead of navigating complex internal review and compliance processes. Meanwhile, platform teams can manage policies centrally. This ensures consistent configurations across the organization and frees time for strategic initiatives. The result is a robust security posture, accelerated innovation, and greater efficiency. Automated guardrails prevent unauthorized configurations. Concurrently, centralized policy management streamlines operations and ensures alignment with corporate and external standards. Resource policies enable organizations to scale securely and innovate without compromise. This empowers developers to move quickly while simplifying governance. Creating resource policies Atlas resource policies are defined using the open-source Cedar policy language , which combines expressiveness with simplicity. Cedar’s concise syntax makes writing and understanding policies easy, streamlining policy creation and management. Resource policies can be created and managed programmatically through infrastructure-as-code tools like Terraform or CloudFormation, or by integrating directly using the Atlas Admin API. To explore what constructing a resource policy looks like in practice, let’s return to our earlier example. This is an organization subject to GDPR requirements that wants to ensure all of their Atlas clusters run on approved cloud providers only. To prevent users from creating clusters on Google Cloud (GCP), the organization could write the following policy named “ Policy Preventing GCP Clusters .” This policy forbids creating or editing a cluster when the cloud provider is Google Cloud. The body defines the behavior of the policy in the human and machine-readable Cedar language. If required, ‘ gcp ’ could be replaced with ‘ aws ’. Figure 1. Example resource policy preventing the creation of Atlas clusters on GCP. Alternatively, the policy could allow users to create clusters only on Google Cloud with the following policy named “Policy Allowing Only GCP Clusters”. This policy uses the Cedar clause “unless” to restrict creating or editing a cluster unless it is on GCP. Figure 2. Example resource policy that restricts cluster creation to GCP only. Policies can also have compound elements. For example, an organization can create a project-specific policy that only enforces the creation of clusters in GCP for the Project with ID 6217f7fff7957854e2d09179 . Figure 3. Example resource policy that restricts cluster creation to GCP only for a specific project. And, as shown in Figure 4, another policy might restrict cluster deployments on GCP as well as on two unapproved AWS regions: US-EAST-1 and US-WEST-1. Figure 4. Example resource policy restricting cluster deployments on GCP as well as AWS regions US-EAST-1 and US-WEST-1. Getting started with resource policies Resource policies are available now in MongoDB Atlas in public preview. Get started creating and managing resource policies programmatically using infrastructure-as-code tools like Terraform or CloudFormation. Alternatively, integrate directly with the Atlas Admin API. Support for managing resource policies in the Atlas user interface is expected by mid-2025. Use the resources below to learn more about resource policies. Feature documentation Postman Collection Atlas Administration API documentation Terraform Provider documentation AWS CDK AWS Cloud Formation documentation 1 McKinsey & Company , August 2024 2 gdpr.eu

February 10, 2025