Document databases – understanding your options

At Open Source Summit Europe in August, the Linux Foundation announced that DocumentDB—a MongoDB-compatible document database built on PostgreSQL—had joined the foundation as a new open source project. This new project, first announced by Microsoft in early 2025, is designed to support developers in deploying databases with their applications quickly and make querying data easier. But this move does make planning around the selection of the document database even harder. There are now more options open to you, so how do you pick the right approach that will suit you now and in the future?

Why choose a document database?

To start with, we’ll look at why you might choose to use a document database over a more traditional relational database. Document databases store data in a format that can be easier to operate using JavaScript Object Notation (JSON). For developers who are not familiar with the intricacies of relational databases or who don’t yet know what data schema they will need over time, using a document database can be faster and more effective in their workflow.

With rapid prototyping and agile development, interest in document databases grew massively. The poster child for this was MongoDB, which currently boasts more than 59,000 customers. Over the past decade, MongoDB has become one of the most popular options for developers who just wanted to get building. Other companies have launched their own document database projects, while MongoDB API-compatible services are also on the market too. The launch of DocumentDB as a Linux Foundation project will open up other new options too.

What infrastructure approach to take now?

There are two decisions to take around databases today—what you choose to run, and how you choose to run it. The latter choice covers a range of different deployment options, from implementing your own instance of a technology on your own hardware and storage, through to picking a database as a service where all the infrastructure is abstracted away and you only see an API. In between, you can look at hosting your own instances in the cloud, where you manage the software while the cloud service provider runs the infrastructure, or adopt a managed service where you still decide on the design but everything else is done for you.

In these circumstances, look at your team and how much time and resources you have available to manage infrastructure, and estimate how much you value your control over that infrastructure as well. On one side, you have the speed of delivery that managed services can provide. On the other, with more control, you can optimize your database to your application’s needs, achieving better performance.

One of the hidden challenges of using cloud services is how much you can be locked into that provider’s way of doing things. You are also beholden to their costs and pricing. If you are not able to migrate your systems away, then you may have to absorb higher costs when your provider raises prices. This can then affect your development strategies, where you have to change your plans based on matters outside your control.

This is partly why more options for running document databases—and MongoDB-compatible database services in particular—have hit the market. MongoDB’s approach to encouraging companies to move to its Atlas cloud service is popular with some, but other companies either can’t or won’t commit to the cloud. Their choice is to carry on with more expensive licenses or find an alternative approach.

What are your options for running document database instances?

While DocumentDB becoming a Linux Foundation project may encourage more migration, it is not the only option available. For organizations that already use MongoDB, shifting to another option can help them retain control over their technology strategy in the future.

The first option is to look at alternative approaches to running MongoDB itself. Alongside MongoDB-compatible APIs, you can choose to run different versions of MongoDB or alternatives to meet your document database needs. For example, you may not want to move to the cloud to run MongoDB Atlas, and it may be cost-prohibitive to stay with MongoDB Enterprise. One approach here is to use MongoDB Community Edition, as this reduces the cost of the license involved. However, this may not cover all the functionality that you need for enterprise-class workloads.

If this is the case, consider an alternative distribution that uses MongoDB but also adds enterprise-class features like backup and security functionality. One example of this is Percona Server for MongoDB, which adds that necessary support and makes functionality available while still being compatible with the SSPL. Using a different distribution offers the most compatibility with existing MongoDB applications while being a sound option for those who want to get started with MongoDB without being specifically tied to MongoDB Atlas or MongoDB Enterprise.

The second migration option is to use a service that is compatible with MongoDB’s API. For some workloads, being compatible with the API will be enough to move to another service with minimal to no impact. This is how DocumentDB works in practice. Whereas DocumentDB’s API is the same as MongoDB, its back-end infrastructure is based on PostgreSQL. Alongside the Linux Foundation DocumentDB project, there are other cloud services that provide compatibility. For example, AWS has a DocumentDB service with MongoDB support, while Microsoft has CosmosDB for MongoDB. Another option is FerretDB, which is an open-source project that replicates the MongoDB drivers and allows them to work on top of PostgreSQL.

The third option is to use an alternative document database. In the world of open source, Apache CouchDB is another document database that works with JSON and can be used for projects. It is particularly useful where applications might run on mobile devices as well as cloud instances; mobile support is a feature that MongoDB has deprecated. However, migrating to CouchDB can involve some changes to the application design. Naturally, the cost of any potential refactoring or re-design should be included in the list of considerations.

To make your choice here, consider how important compatibility with MongoDB is for your applications. If you need to implement the full MongoDB stack, then your best option is to use MongoDB or a drop-in distribution. If you just need compatibility with the APIs or drivers, then you have more options available. If you want or need to run in private cloud environments, the choice is more limited. Approaches like using databases in container environments managed with Kubernetes operators can deliver the equivalent functionality that cloud services offer, while not locking you into specific cloud service providers. This can also fit into a platform engineering model where you can automate the allocation of resources, deployment, and management for those instances over time, too.

The long-term future for MongoDB and document databases

MongoDB is still the most popular NoSQL document database for developers, sitting at #6 in the overall database ranking in the StackOverflow Survey 2025. That popularity won’t drop anytime soon. But there are more options available to run those workloads than ever before. Rather than relying on one company’s investment in the project, there is a whole community now available and invested in developing their own approaches to document databases.

The evolution of the wider technology landscape will also affect the future for document databases. The demand for AI services has increased the value that company data can provide, and turning data into vector embeddings for generative AI projects has in turn led to more document database deployments to support that data. For developers, using document databases to store their company data as vectors makes it easier to manage this data in parallel.

This rise in options should help to cement MongoDB as a technology approach for the long-term future, just as SQL has been adopted and used as a standard for relational databases for more than 50 years. But there are now more approaches to use this approach than ever before, from compatible distributions through to projects that use the APIs or support the drivers while adopting other infrastructure approaches.

All of this innovation demonstrates the continued love for the document database approach, but developers want more options and choice around how they build. The open source community has stepped in to meet those needs, from adopting new distributions to delivering more choice around how to use this approach.

—

New Tech Forum provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to doug_dineley@foundryco.com.