The most valuable feature of Azure Cosmos DB is its scalability. That is the biggest reason I use Azure Cosmos DB. I also like its developer-friendliness. It is very easy to begin with. Microsoft and Azure are good with that. With all the getting started information and all the introductions, it is very easy to begin with. Optimization is where it gets a bit trickier. That is where you need to be more active and understand why things are not performing as they used to. Most of the time, performance is not a problem. It is always fast. The problem is more around the cost consequence of that performance. Its vector capabilities are new. They were implemented just months ago. There are probably three things that we were looking to address by using the vector database. The number one is the cost of Azure AI search and indexing. Before this feature came out in Azure Cosmos DB, the alternative for me was using AI search, which is way more expensive if using it as a vector database. Now with Azure Cosmos DB, that price point becomes much more accessible. That is number one. Number two is the developer familiarity aspect of things. AI search is more around enterprise use cases or enterprise search and requires more specialized skills to begin with, whereas Azure Cosmos DB is more or less a commoditized developer platform that is much more accessible to a wider developer audience. That is another aspect that it has addressed. For example, if I have a new starter in my team, it is easier to train that person on Azure Cosmos DB than the AI search. With the explosion of LLMs, AI agents, and things like that, the vector database on Azure Cosmos DB is a good place for developer onboarding. It is just way easier. The third part is still related to the developer experience, but in terms of the SDK aspect, the libraries available for Azure Cosmos DB are already well-established in the ecosystem. With the vector database capability, it is just a matter of adding an extension of those existing libraries. That means if the applications that are already using Azure Cosmos DB want to jump to the vector database, the jump would not be that big. It is just a matter of implementing it directly with their existing Azure Cosmos DB that they are already using. We have used the vector database with Azure AI services. The other aspect is using the vector database with document intelligence. We use document intelligence to process a raw PDF document and things like that. From there, we convert that into embeddings, and then those embeddings will be stored in the vector database. It is something we use as a landing spot for new LLM applications. The quality has improved because, traditionally, we did things in batches. We processed documents once a day or every twelve hours or so. With this new capability, we are very confident to run those processes in real-time. As new documents come in, the process and the workflow can get triggered. It is not a batch anymore. It is in real-time. Azure Cosmos DB’s ability to search through large amounts of data is yet to be determined. Large is subjective at the moment. I have only tested it up to 2 gigabytes, and for that, it is working pretty well. Azure Cosmos DB is our default. We do not question it anymore. After migrating out applications from an SQL database to Azure Cosmos DB, the change in the organization is massive. Especially on the application side of things, app developers are much more productive and lean. Previously, we had to go through a very rigorous process. To add new columns, tables, and other things, we had to work with DBAs. With Azure Cosmos DB, we can have a PoC and POV in weeks, sometimes days, instead of six months. That is how the whole NoSQL ecosystem changed our life cycle and productivity. Azure Cosmos DB has changed our total cost of ownership for old applications, but not for new applications. For those who are still using SQL Servers or other databases, there was an added TCO because different projects are using different databases, whereas about 10 or 15 years ago, we had just Oracle, SQL Server, or IBM. For new applications, it is the default for us, so there is no change in TCO.
