I would recommend using Qdrant as the vector database for this requirement. It is a vector-native database, purpose-built for high-performance similarity search, and generally provides very good response times for vector workloads. Its clustering and distributed deployment are relatively straightforward to set up, and for production workloads, NVMe SSDs should be preferred to achieve the best I/O and indexing performance. Qdrant can also leverage GPU acceleration where required, depending on the workload and deployment configuration. However, I would suggest first setting up Qdrant in a Docker-based environment, integrating it with the application, and testing it against the actual expected data volume, vector dimensions, query patterns, and response-time requirements. Based on those benchmark results, we can make the final decision on the production architecture and hardware.
Typically, we do not use proprietary databases such as Microsoft Azure or Horizon DB, and we have been using primarily open source databases. If you are talking about databases, primarily it is PostgreSQL or MySQL. If you call us regarding vector databases, mostly it is Qdrant. Qdrant and Weaviate are partly paid and partly proprietary. I am a hands-on data scientist-cum-engineer, so I have used it myself. If you need to evaluate vector databases, Qdrant is among the very few databases where you can do a hybrid search. Qdrant is one of the few vector databases which does a hybrid search. By hybrid search, I mean searching through semantics, that is meaning, and also through word matching. Improving the model involves a lot of things, including hybrid search, reranking of results, and many other things are involved. Qdrant is a good and scalable vector database, and it is free. They have a free version. Their cloud services are paid, while the on-premise ones are free. Multiple query languages we have not used, primarily it is English. Multiple query languages would involve a different thing, such as translating the query and then searching the database, so that is a different ball game itself. In indexing and retrieving vectors, there are certain features which are not available as far as Chroma is concerned. You can store a feature of having metadata where, in vector databases or in RAG systems, things become more and more complex. In Qdrant, you can do that. I would rate this product an overall 8 out of 10.
My advice for others looking into using Qdrant is to test it first by using Qdrant Cloud platform, which will give a very good idea of how it works and how it behaves. This way, if proceeding to a full enterprise version or another deployment option, it would be easier to work with. I have given this review a rating of nine out of ten.
Qdrant is one of the best vector databases out there that is also open source. It is pretty good and has all the batteries I need. I think it is a great product for anyone looking to build their whole stack and also self-host them. Qdrant gives the flexibility to do it. Most vector databases support pretty much everything that a batteries-included full-fledged vector database should offer. However, the best thing about Qdrant is, first of all, it is open source. Second, it has very standardized client libraries for pretty much anything out there. It also benefits from being open source. Being open source and being pretty fast makes Qdrant stand out. There are plenty of open source databases out there, but Qdrant is the most complete one that is also pretty fast. These are the two things that make Qdrant a much better choice than any other vector databases. I mainly use Python and Rust, and Qdrant itself is written in Rust, which provides really good uses. I have used something like Chroma and Chroma is quite good, but it does not really scale for huge documents where Qdrant actually scales really well. That is why I call this the most complete package out there. Chroma is pretty good, but it does not really scale well. Pinecone is not open source, so it is also a bit of a hassle to self-host. Qdrant shines really well here. If someone needs something that is super fast for a tiny application, Qdrant might not be the best option. However, if someone is looking for scale or dealing with huge documents and medium to huge documents, Qdrant is a really good choice, especially if they want something that can be self-hosted and is open source. Qdrant is the best one out there for those needs. For smaller applications, someone should be looking into something Chroma or even DiskANN, which is by Microsoft. Qdrant is for medium to larger scale applications, not for tiny scale. For tiny scale, it is a bit of an overkill. My overall rating for Qdrant is seven point five out of ten.
My advice for those considering Qdrant is that it serves as an excellent starting point for any RAG workloads. The most practical recommendation is to first assess your stack complexity. Before committing to a dedicated vector database, evaluate if your existing primary database meets your scale. While Qdrant is fast, maintaining a separate database may lead to significant synchronization issues and DevOps overhead. If your needs involve under a few million vectors without extreme load sub-millisecond search latencies, consolidating your setup into a single database can alleviate engineering challenges effectively. I would rate this product an 8 out of 10.
My advice for others looking into using Qdrant is to understand how a vector database works, including how embedding should be done before it is passed into the database. Familiarizing oneself with how the HNSW search functions internally is crucial. I also suggest starting with simpler vector databases like Faiss before progressing to Qdrant, which is distinctly superior as a modern vector database. I believe I have covered all points regarding Qdrant. It is definitely worth using for teams engaged in either coded or no-code platforms. I was pleasantly surprised to learn that I could build something on a no-code platform using Qdrant Cloud, which intrigued me greatly. I think Qdrant Cloud offers significant benefits, especially in saving time while developing no-code automation projects, similar to what would have been achieved with coding. I would rate this product a nine out of ten.
We are using the default query language for Qdrant, and we have not used anything else. Whatever Qdrant provides by default, we are using it, and we are satisfied with that. The metrics I use to evaluate the performance in indexing and retrieving vectors with Qdrant focus on response time. Response time is the primary metric. Qdrant has reduced our response time to less than one second for our 128 KB token sizes, and we are satisfied with that performance. Qdrant is open source, which means the software is free if you handle it yourself, but you need one or two engineers working on it. Since it is free, it is very good compared to other databases. I rate this review an overall 8.
Currently, we are using a vector database called Qdrant, but most of our tasks are agentic, and we don't have it anymore. I can answer a few questions about Qdrant. I have used Qdrant's hybrid search capability. The use of multiple query languages has impacted my data query processes mostly as Q&A. We use the Ragas metrics to evaluate Qdrant's performance in indexing and retrieving vectors. All the metrics I consider in Ragas are useful. In my company, we have around eight or nine people using Qdrant. I think Qdrant is popular enough in my region, but they can probably promote it more. I rate this review a 9 out of 10.
Qdrant is a powerful tool for efficiently organizing and searching large volumes of data. It is particularly useful for tasks such as data indexing, similarity search, and recommendation systems.
With fast and accurate results, it is suitable for various applications including e-commerce, content management, and data analysis. Users appreciate Qdrant's efficient search capabilities, high performance, and ease of use.
Its quick and accurate retrieval of relevant information allows...
I would recommend using Qdrant as the vector database for this requirement. It is a vector-native database, purpose-built for high-performance similarity search, and generally provides very good response times for vector workloads. Its clustering and distributed deployment are relatively straightforward to set up, and for production workloads, NVMe SSDs should be preferred to achieve the best I/O and indexing performance. Qdrant can also leverage GPU acceleration where required, depending on the workload and deployment configuration. However, I would suggest first setting up Qdrant in a Docker-based environment, integrating it with the application, and testing it against the actual expected data volume, vector dimensions, query patterns, and response-time requirements. Based on those benchmark results, we can make the final decision on the production architecture and hardware.
Typically, we do not use proprietary databases such as Microsoft Azure or Horizon DB, and we have been using primarily open source databases. If you are talking about databases, primarily it is PostgreSQL or MySQL. If you call us regarding vector databases, mostly it is Qdrant. Qdrant and Weaviate are partly paid and partly proprietary. I am a hands-on data scientist-cum-engineer, so I have used it myself. If you need to evaluate vector databases, Qdrant is among the very few databases where you can do a hybrid search. Qdrant is one of the few vector databases which does a hybrid search. By hybrid search, I mean searching through semantics, that is meaning, and also through word matching. Improving the model involves a lot of things, including hybrid search, reranking of results, and many other things are involved. Qdrant is a good and scalable vector database, and it is free. They have a free version. Their cloud services are paid, while the on-premise ones are free. Multiple query languages we have not used, primarily it is English. Multiple query languages would involve a different thing, such as translating the query and then searching the database, so that is a different ball game itself. In indexing and retrieving vectors, there are certain features which are not available as far as Chroma is concerned. You can store a feature of having metadata where, in vector databases or in RAG systems, things become more and more complex. In Qdrant, you can do that. I would rate this product an overall 8 out of 10.
My advice for others looking into using Qdrant is to test it first by using Qdrant Cloud platform, which will give a very good idea of how it works and how it behaves. This way, if proceeding to a full enterprise version or another deployment option, it would be easier to work with. I have given this review a rating of nine out of ten.
Qdrant is one of the best vector databases out there that is also open source. It is pretty good and has all the batteries I need. I think it is a great product for anyone looking to build their whole stack and also self-host them. Qdrant gives the flexibility to do it. Most vector databases support pretty much everything that a batteries-included full-fledged vector database should offer. However, the best thing about Qdrant is, first of all, it is open source. Second, it has very standardized client libraries for pretty much anything out there. It also benefits from being open source. Being open source and being pretty fast makes Qdrant stand out. There are plenty of open source databases out there, but Qdrant is the most complete one that is also pretty fast. These are the two things that make Qdrant a much better choice than any other vector databases. I mainly use Python and Rust, and Qdrant itself is written in Rust, which provides really good uses. I have used something like Chroma and Chroma is quite good, but it does not really scale for huge documents where Qdrant actually scales really well. That is why I call this the most complete package out there. Chroma is pretty good, but it does not really scale well. Pinecone is not open source, so it is also a bit of a hassle to self-host. Qdrant shines really well here. If someone needs something that is super fast for a tiny application, Qdrant might not be the best option. However, if someone is looking for scale or dealing with huge documents and medium to huge documents, Qdrant is a really good choice, especially if they want something that can be self-hosted and is open source. Qdrant is the best one out there for those needs. For smaller applications, someone should be looking into something Chroma or even DiskANN, which is by Microsoft. Qdrant is for medium to larger scale applications, not for tiny scale. For tiny scale, it is a bit of an overkill. My overall rating for Qdrant is seven point five out of ten.
My advice for those considering Qdrant is that it serves as an excellent starting point for any RAG workloads. The most practical recommendation is to first assess your stack complexity. Before committing to a dedicated vector database, evaluate if your existing primary database meets your scale. While Qdrant is fast, maintaining a separate database may lead to significant synchronization issues and DevOps overhead. If your needs involve under a few million vectors without extreme load sub-millisecond search latencies, consolidating your setup into a single database can alleviate engineering challenges effectively. I would rate this product an 8 out of 10.
My advice for others looking into using Qdrant is to understand how a vector database works, including how embedding should be done before it is passed into the database. Familiarizing oneself with how the HNSW search functions internally is crucial. I also suggest starting with simpler vector databases like Faiss before progressing to Qdrant, which is distinctly superior as a modern vector database. I believe I have covered all points regarding Qdrant. It is definitely worth using for teams engaged in either coded or no-code platforms. I was pleasantly surprised to learn that I could build something on a no-code platform using Qdrant Cloud, which intrigued me greatly. I think Qdrant Cloud offers significant benefits, especially in saving time while developing no-code automation projects, similar to what would have been achieved with coding. I would rate this product a nine out of ten.
We are using the default query language for Qdrant, and we have not used anything else. Whatever Qdrant provides by default, we are using it, and we are satisfied with that. The metrics I use to evaluate the performance in indexing and retrieving vectors with Qdrant focus on response time. Response time is the primary metric. Qdrant has reduced our response time to less than one second for our 128 KB token sizes, and we are satisfied with that performance. Qdrant is open source, which means the software is free if you handle it yourself, but you need one or two engineers working on it. Since it is free, it is very good compared to other databases. I rate this review an overall 8.
Currently, we are using a vector database called Qdrant, but most of our tasks are agentic, and we don't have it anymore. I can answer a few questions about Qdrant. I have used Qdrant's hybrid search capability. The use of multiple query languages has impacted my data query processes mostly as Q&A. We use the Ragas metrics to evaluate Qdrant's performance in indexing and retrieving vectors. All the metrics I consider in Ragas are useful. In my company, we have around eight or nine people using Qdrant. I think Qdrant is popular enough in my region, but they can probably promote it more. I rate this review a 9 out of 10.