For integrating Microsoft Azure Cosmos DB with other Azure products or other products, there are a couple of challenges with the current system. Right now, the vectors are stored as floating-point numbers within the NoSQL document, which makes them inefficiently large. This leads to increased storage space requirements, and searching through a vast number of documents in the vector database becomes quite costly in terms of RUs. While the integration works well, the expense associated with it is relatively high. I would really like to see a reduction in costs for their vector search, as it is currently on the expensive side. The areas for improvement in Microsoft Azure Cosmos DB are vector pricing and vector indexing patterns, which are unintuitive and not well described. I would also like to see the parameters of Fleet Spaces made more powerful, as currently, it's somewhat lightweight. I believe they've made those changes intentionally to better understand the cost model. However, we would like to take a more aggressive approach in using it. One of the most frustrating aspects of Microsoft Azure Cosmos DB right now is that you can only store one vector per document. Additionally, you must specify the configuration of that vector when you create an instance of Microsoft Azure Cosmos DB. Once the database is set up, you can't change the vector configuration, which is incredibly limiting for experimentation. You want the ability to try different settings and see how they perform, as there are numerous use cases for storing more than one vector in a document. While interoperability within the vector database is acceptable—for example, I can search for vectors—I still desire a richer set of configuration options.
