Qdrant Reviews

My main use case was utilizing Qdrant as a vector database to store documents in vector format, which made searching easier whenever a query was passed. I implemented it in a chatbot, specifically a RAG chatbot, which stands for Retrieval-Augmented Generation. I stored the business documents of companies into Qdrant's knowledge base or vector database.

Using Qdrant as my vector database for the RAG chatbot definitely helped with document search and chatbot accuracy. Initially, it was very easy to implement vector search in Qdrant and to embed the documents that needed to be stored. The RAG chatbot was a simple PDF stored in the knowledge base in properly defined chunks and could be queried anytime when a question was passed. Accuracy-wise, the chatbot achieved approximately seventy percent accuracy, although it needed more fine-tuning and guardrails to make it more accurate, which was insightful for me in using Qdrant.

Regarding my main use case and experience using Qdrant for my RAG chatbot and document search, I started by coding and implementing the RAG chatbot alongside Qdrant as a vector database. Recently, I discovered an innovative way of using Qdrant, which is Qdrant Cloud. This allows users to utilize Qdrant not just in coding projects but also in no-code projects. As an AI automation engineer, I have created no-code automations for HR and recruiting agencies, such as an ATS screener and resume screener, where I built a proper vector database for the recruiting agency to store all the resumes they have. They can query the top N results matching their job descriptions without me needing to code the entire solution, thanks to Qdrant Cloud. It made implementation much easier and took me less than a week, whereas a coded project would normally take at least a month.

One of the best features Qdrant offers is definitely Qdrant Cloud, as it can be easily deployed and implemented in no-code platforms without limitations tied to a coding approach. Additionally, the HNSW method for searching through the vector database is very fast and accurate compared to just normal similarity search that most vector databases provide. Moreover, Qdrant allows users to view how the vectors are stored, including checking the three-dimensional diagrams of the stored vectors.

The specific feature that helped me solve problems or save time is Qdrant Cloud, especially when I built a resume screener for the recruiting agency in under a week. This significant time-saving benefit comes from using Qdrant Cloud in no-code automation workflows. Another use case I had was creating a complete vector database for the company, where I stored contracts in PDF format. This allows the company's founder to query the bot and swiftly get accurate answers about these documents, enhancing the whole process significantly in terms of speed and simplicity due to the easier access provided by Qdrant Cloud.

One of the best features Qdrant offers is definitely Qdrant Cloud, as it can be easily deployed and implemented in no-code platforms without limitations tied to a coding approach. Additionally, the HNSW method for searching through the vector database is very fast and accurate compared to just normal similarity search that most vector databases provide. Moreover, Qdrant allows users to view how the vectors are stored, including checking the three-dimensional diagrams of the stored vectors.

Qdrant has positively impacted my organization by consuming much less time than building systems through coding. It is vital for the business to consider how much time is needed to achieve a specific output. For instance, my project for the recruiting agency would have taken a month using a coded approach, but thanks to Qdrant Cloud and the HNSW accurate searching method, the company saved at least three weeks of time. The greater accuracy of query answers when using Qdrant also matters significantly for us.

Beyond time saved and improved accuracy, another measurable outcome is cost savings. Instead of using subscription-based platforms like Weaviate, Qdrant offers a free tier, especially on Qdrant Cloud, which makes it easier for us to utilize Qdrant Cloud for free without costs. While we initially may not have many use cases, I believe that as we grow, moving to a paid plan will not be an issue due to the positive results we have seen over these months.

I see room for improvement in Qdrant based on what another platform called Weaviate offers. Qdrant provides an excellent vector database with a solid searching method. However, it could elevate its offering by integrating embedding features. Currently, for the workflow automation I build, I rely on other platforms for embedding, so incorporating this feature directly in Qdrant Cloud would eliminate the need to depend on external solutions.

A pain point I have encountered was the inactive expiration of the cloud created for certain projects. If the cloud is not used for a week, it gets terminated, which is frustrating. I think increasing that inactivity window in the free tier would be beneficial, as I have faced limitations due to this seven-day inactivity rule, requiring me to reset up the cloud after its termination.

I used Qdrant during my first internship, which was approximately eight to ten months ago.

Qdrant is stable, except for the limitation concerning the termination of inactive clouds after a week. Other than that, it operates reliably.

Qdrant is definitely scalable. In the recruiting agency project, the reliance on the vector database has expanded from storing hundreds of resumes to thousands, demonstrating its scalability and impressing the company with the results.

I have not had any need to contact Qdrant's customer support. The documentation provided by Qdrant covers most queries effectively, and I foresee no need for support in the near future.

I previously used a different solution before Qdrant called Faiss, which is Facebook's vector database. While it was user-friendly for understanding the basics, it does not match the accuracy of Qdrant. Therefore, I switched to Qdrant Cloud due to its higher accuracy resulting from the HNSW searching method.

There is definitely a return on investment with Qdrant. Although I am on a free tier and therefore have zero investment, the results obtained have been excellent for a vector database. The time saved is substantial, with nearly three weeks or more for projects deployed with Qdrant Cloud in no-code platforms. The accuracy achieved through HNSW searching compared to others is notable.

There is definitely a return on investment with Qdrant. Although I am on a free tier and therefore have zero investment, the results obtained have been excellent for a vector database. The time saved is substantial, with nearly three weeks or more for projects deployed with Qdrant Cloud in no-code platforms. The accuracy achieved through HNSW searching compared to others is notable.

Regarding pricing, setup costs, and licensing, since I am using only the free tier of Qdrant Cloud, there are no setup costs involved. Moving forward, as the company grows, I will consider options for a paid plan with Qdrant.

Before choosing Qdrant, I evaluated other options, including Faiss, Weaviate, and Pinecone. Ultimately, I selected Qdrant for its higher accuracy and lower cost compared to other alternatives.

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.

I have been using Qdrant for almost one and a half years. This was actually one of the first vector databases that we picked up in our organization. We started using the RAG modules to create a personalized company-based AI or a company-based LLM which would help answer questions from the employees, and we used Qdrant to store all the documentation, resources, and all other help links and help documents parsed into vector databases. After that, we moved into using Supabase vectors.

The main use case for Qdrant was to upload help resources and articles, as we have a repository of helpful resources or help documentation which the team can refer to in order to do a particular thing. For example, there is a workflow for how to onboard a new team member. The entire workflow has been broken down into multiple different steps and multiple different checklists, which is maintained in a documentation. This documentation can be given to a team member for a better understanding to follow the process through and onboard a team member. What we did is we used Qdrant to create a vector database where we can store all of these documents, creating embeddings out of them and storing them in the vector database in Qdrant. This can then be referred to by an LLM agent that retrieves these documents or answers based on inquiries. Instead of giving someone this document, we can give them access to the agent, and they can ask how to onboard a team member. The agent would refer to the document from Qdrant based on the vector database, fetch the results, and show them the exact contents of the document in a proper LLM format with checklists, allowing users to ask further questions for context.

Qdrant's impact on our organization was most evident in developer velocity and self-service troubleshooting during the time it was actively utilized for our documentation and RAG system. This approach allowed the team to avoid monotonous documentation searches; instead, they could interact with an LLM agent that fetched documentation contextually. Rather than taking days for technical issues to be resolved through traditional ticketing, issues can be solved in one to two days, thanks to self-diagnosis capability. The integration of an LLM agent reduces repetitive inquiries, allowing new team members to find answers independently rather than burdening senior engineers. Additionally, Qdrant's search latency was impressive, operating under 10 milliseconds for vector retrieval, allowing opportunity for real-time context in conversations with the LLM. This swift access to information enables ongoing improvements to our documentation based on user interactions, signaling gaps when low-confidence queries arise.

All of the features mentioned stand out for me; definitely, payload filtering is one of the primary reasons we used Qdrant initially. In many vector stores, we can filter by metadata either pre- or post-search, each with drawbacks. Pre-filtering risks over-restriction while post-filtering can yield unsatisfactory results. Qdrant's integration of payload index is excellent for setting up an HNSW graph, allowing metadata constraints to be resolved during graph traversal. For our onboarding case discussed, this means searching how to deploy code can be dynamically constrained to a specific role, ensuring precision and speed. Furthermore, the developer experience is enhanced by Qdrant's open-source nature, making it flexible and easily deployable. For an EdTech company with an active engineering team, reducing friction in adopting new technology is crucial, and Qdrant's open-source nature allows local instance setups without enterprise contracts, simplifying the deployment process. Scalability and fast search are core strengths, but managing scalability can require dedicated infrastructure, which led us to consider alternatives such as Supabase Vector.

Several specific details stand out about Qdrant's features, particularly for a company prioritizing low-code or no-code environments. The built-in UI for Qdrant is a very nice, interactive console that allows running dashboards and inspecting data without needing third-party GUI clients or custom scripts, as Qdrant includes a built-in console to simplify REST queries directly in the browser. Additionally, the recommendation API is notable; unlike many other vector databases that only support direct searches, Qdrant allows specifying positive and negative vector IDs as inputs. This unique feature enables tailored recommendations without needing to retrain models or develop complex ranking algorithms, making it invaluable for applications such as an onboarding system or a student-facing LMS.

While Qdrant is an exceptionally fast and efficient search engine within vector bases, our engineering team faced operational challenges during its adoption. Architectural complexity was a key friction point, as our primary database was set in Supabase, necessitating synchronization of two separate systems for user data, permissions, and states. The dual database setup meant every operation required updates to both Supabase and Qdrant, which risked falling out of sync if any issues arose with API calls, complicating developer efforts. Additionally, while Qdrant's payload filtering is powerful, the JSON-based domain-specific language can be verbose and challenging for developers skilled in SQL. The operational load of maintaining Qdrant as a standalone service introduced additional strain, requiring backups and monitoring independent from Supabase, which detracted from time spent on product features. Moreover, the absence of native relational joins complicates queries dependent on SQL data, necessitating segmented queries that can escalate network latency.

I have been using Qdrant for almost one and a half years.

In my experience, Qdrant is stable.

Qdrant exhibits quite good scalability.

Customer support for Qdrant is quite good.

We did not use any other solution before Qdrant; we transitioned from Qdrant to Supabase later.

Technically, we are not really using Qdrant now, though we used it extensively for a long time, gaining better perspectives on vector stores and RAG systems for our own company, functioning as a help bot. We can query anything from Slack and retrieve data back for insights. When we were using Qdrant, we deployed it through Docker in a private cloud.

For this specific workflow, we had to build an internal RAG system for team onboarding and documentation, using team onboarding as a particular example. The decision to choose Qdrant over other options was driven by operational and technical factors, particularly its advanced payload filtering for document segmentation. Internal documentation is rarely a flat pool of information; it is segmented by department with each team having its own set of documents. For instance, an HR team member would utilize onboarding documentation that serves as a checklist, while also having access to policy documentation such as offboarding procedures. This complex data pool made it tough to find the right document for a given workflow. Qdrant stood out due to its ability to perform single-stage filtering on payloads, allowing us to query the database with metadata filters set in place. Whenever we took a document and made embeddings, we assigned metadata tags to each document, facilitating efficient retrieval by relevance. Additionally, as an EdTech company with an active engineering team, developer velocity and ease of local testing are highly important. Qdrant, built on Rust for resource efficiency, can be easily set up locally, avoiding the need for high-level cloud virtual machines. Its well-documented SDK and open-source nature also contributed to our choice over other options.

We saw a clear return on investment from Qdrant, particularly in the engineering time saved and the empowerment of team members to handle self-service tasks instead of reducing headcount. The most significant ROI stemmed from improved ticket resolution time, with issues being solved rapidly as the team became more autonomous. Thanks to Qdrant's open-source nature, our initial licensing and setup costs were nearly zero, allowing for swift testing and launch of our RAG prototype. Although maintaining dual databases created some complications, switching to Supabase Vector preserved those productivity enhancements while significantly alleviating DevOps time and reducing costs.

Licensing posed no issues, as Qdrant is open-source software with no upfront fees. Initially, the setup cost was low since we utilized a self-hosted model on a small cloud VM. However, as we added documentation, vector costs rose. The hidden factor was high, primarily from the developer time spent on backup management and complex sync pipelines between Qdrant and Supabase. While Qdrant itself is economically viable, consolidating to Supabase vectors ultimately saved costs associated with maintaining a unified vector base.

Before choosing Qdrant, we evaluated a few alternatives such as Pinecone, Milvus, and Chroma. However, Qdrant's open-source nature made it a relatively straightforward choice, especially as we aimed to establish an LLM agent capable of handling our RAG queries. Pinecone's cloud-only restriction was unsuitable, as we sought local deployment without upfront costs. Milvus's enterprise-level complexities were also excessive for our needs, given our team size and straightforward RAG requirements.

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.

Qdrant's main use case is to fetch data through the vector database to populate my RAG AI. When I input data into the RAG AI, Qdrant stores the text, images, or other data as embeddings, or vectors, and it helps the RAG system retrieve the most semantically relevant information based on user input. The most common data types could be text, images, audio, or any data that can be converted into a vector. Once I put the user input, it provides an output through those embeddings.

That is the main workflow I've been using Qdrant for the past year. I've also been using it in LangChain because it works really well with LangChain. Beyond that, I use Qdrant to upload snapshots as well.

Qdrant's most important feature is that it is very fast because it tends to give the results quickly. It is also very compatible with Python because Qdrant has first-class Python support. I can quickly install it on my machines with a PIP install Qdrant client, allowing me to work smoothly.

The other important feature is its cloud capability. Qdrant offers self-hosting, and I am using it from Docker, which is a significant advantage. It has high performance and is good for flexible deployment. Another main advantage is that it is very cost-efficient since it is open source.

The biggest importance I have seen in Qdrant is its high performance. It is a Rust-based engine with very low latency and HNSW indexing. High performance is a big plus when using Qdrant, especially when I need to fetch data through the vector database for RAG AI, as it tends to provide outputs quickly. Since I use Python, it is very fast and API friendly, and that is one of the best things I have experienced.

Qdrant works well with LLM web frameworks, especially with native support in LangChain, where the integration is pretty easy from the LangChain perspective.

Qdrant has improved my efficiency and is really easy to integrate. It is self-hosted, so integration is straightforward. I believe it offers many advantages compared to what I have used alternatively before.

Qdrant has saved a lot of time and has improved efficiency and reduced costs since it is open source and very cost-effective. Although I cannot specify a particular number, I estimate that I have saved about 50 to 60 percent of the time by using Qdrant. There is no extra charge since it is open source, which is a significant benefit.

I can suggest several improvements for Qdrant. The first one is better native embedding and re-ranking support. Qdrant currently functions as a storage plus retrieval engine, not as a reasoning system, so built-in embedding generation or built-in re-ranker models, or a smarter query understanding layer could reduce dependency on external machine learning services. Additionally, fast large-scale filtering operations could be implemented, such as automatic index suggestions, adaptive query planning, and smart indexing of metadata fields, which would make Qdrant even more efficient. Another observed limitation is a metadata filtering strategy where users can filter by user ID, document type, time, or domain, which reduces noise significantly.

Another needed improvement is deduplication plus versioning, as it can enhance quality by removing duplicate chunks and versioning embeddings when documents update. From a production perspective, addressing retrieval latency and embedding drift by observing failed queries would be important, allowing Qdrant to fit OpenTelemetry perfectly as well.

One of the key limitations is that Qdrant does not have built-in role-based access control, and while being self-hosted is a benefit, it can also be improved. There is also no automatic governance policy, so I must design my own access rules, retention rules, or versioning. Additionally, there is no native encryption of payload fields to manage at the infrastructure or app level.

It would be a perfect 10 if Qdrant could reduce noise, especially by eliminating duplicate chunks. Another thing would be having built-in re-ranker models. If these improvements were made, I would give it a 10.

I have been using Qdrant for nearly one year.

In my experience, Qdrant is very stable. It is easy to use whether on LangChain or on its own, and it performs well in hosting and retrieving outputs without causing much difficulty, making it a good option for anyone looking for a vector database.

Qdrant handles growing workloads and data volumes well for me, which was a significant reason for my shift from other popular alternatives to Qdrant.

I have not interacted much with customer support because I have not encountered significant issues from a developer's perspective that required me to reach out for help. My operations team also has not had many questions regarding pricing or usage, so I have not experienced major problems needing customer support.

Before using Qdrant, I tried several alternatives such as Pinecone, which also manages vector databases but is more expensive at scale and closed source, and ChromaDB, which is suitable for prototyping but does not perform well for production scaling. In contrast, Qdrant is fast, offers strong filtering, allows easy self-hosting, provides good cloud options, and is simpler to use than Milvus, Weaviate, or Pinecone.

I evaluated several other options, including Pinecone, Weaviate, Milvus, and ChromaDB. They each have downsides, particularly in production scaling, complexity of architecture, or being more resource-intensive compared to Qdrant.

I have seen a significant return on investment from using Qdrant because it is very easy to integrate and highly efficient, saving a lot of time in my day-to-day operations, which ultimately saves money as well. It is productive as I can do more work in less time.

Regarding Qdrant's governance and security, I think it does a decent job because I have not encountered many problems with it. Qdrant runs as an HTTP plus gRPC service, and my advice is never to expose it directly to the internet. Instead, put it behind an NGINX or API Gateway or use a VPN or VPC only access to protect your data from a network security perspective. On authentication or access control, since Qdrant is self-hosted, it lacks built-in role-based access control by default, which is an important limitation. Therefore, you must implement a reverse proxy, JSON Web Token, OAuth 2, or API keys for network-level restrictions to enhance security.

In terms of accuracy and reliability of output, Qdrant retrieves relevant vectors from the documents and chunks I provide, but it does not produce intelligent output, so it does not exhibit AI accuracy. Its accuracy depends on embedding quality, indexing quality, and query formulation quality. On reliability, I think it is very stable and consistent with high availability design, making its behavior predictable. Unlike LLMs, Qdrant does not hallucinate or guess answers; it only returns stored vectors. With the embeddings I have provided, it performs well and exceeds my expectations.

One of the key limitations is that Qdrant does not have built-in role-based access control, and while being self-hosted is a benefit, it can also be improved. There is also no automatic governance policy, so I must design my own access rules, retention rules, or versioning. Additionally, there is no native encryption of payload fields to manage at the infrastructure or app level.

If someone is looking for a vector database that can be easily hosted and integrated with Python to provide outputs quickly while being cost-effective, Qdrant would be a great option. It is also effective when handling large sets of data and fits well with LLM models such as LangChain, making it a top choice for anyone needing a vector database.

Qdrant is an excellent vector database that anyone would want to use with RAG AI. I believe users will benefit significantly from Qdrant, and while they may explore other vector databases, I think they will notice a substantial difference with Qdrant compared to the alternatives. I would rate this product a 9 out of 10.

Our use case for Qdrant is AI data analysis.

The best features of Qdrant are GPU support, which enables very fast processing, and a very light footprint as it uses fewer resources.

I assess the value of Qdrant's ability to handle high-dimensional vectors for our AI projects as very positive. It is able to handle all of the AI workloads we have, and we are currently operating at a chunk size of 128KB, where it performs well.

My thoughts on the hybrid search capabilities of Qdrant are that they are very good.

The area for improvement in Qdrant is its clustering capability. While it has clustering functionality, it is not easy to set up, and not everyone can configure the clustering, so there is room for improvement in the clustering configuration.

Deploying Qdrant is complex when dealing with a cluster. A single node deployment is very easy, but if you want to deploy a cluster, it becomes complex.

We have been using Qdrant for the last two years.

Qdrant requires maintenance. You need to patch Qdrant as soon as patches are released. We always perform minor updates, and for major updates, we consider them based on migration time and other factors. We always apply patches and minor updates.

I rate the technical support of Qdrant as a nine because I think we have never reached out to them directly, but Qdrant has good support available online, and I can get answers from forums. The support is good.

When comparing Qdrant with other databases like MariaDB or TiDB, those databases do not have vector searching capabilities. Qdrant can be compared with other vector databases like Milvus, ClickHouse, and Pinecone. Qdrant operates in its own vector database segment and is good because it supports GPU acceleration, meaning if you can install a graphics card, it will use it, and it has cluster support. There is room for improvement, but it does have cluster support. If you compare other databases like Milvus or Pinecone, they do not have clustering or GPU support; those are very preliminary databases. Qdrant is an enterprise database, and we can rely on it for running enterprise applications. ClickHouse is somewhat comparable to Qdrant, but ClickHouse is a hybrid database rather than a specialized database designed for time series; it is only somewhat comparable to Qdrant.

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.

I use Qdrant mainly as a vector search layer because I specifically chose it to store metadata. I use Qdrant as a search layer in my schemes prediction engine, where after entering personal details, the data is converted to embeddings.

I find Qdrant quite amazing because it is simple and has a Python client that allows for fast local experimentation, making it a good fit for my needs.

The best features Qdrant offers include fast local experimentation and support for both dense and sparse embeddings, which allows for hybrid search.

Hybrid search is really important for semantic matching as well as exact matching, providing significant benefits to my work and my team.

Qdrant has allowed me to build a really good search engine for scheme recommendation, having a positive impact on my organization.

I have seen great improvements in my search results using Qdrant specifically, which enhances my work.

An accuracy boost was definitely observed from 45 to 50% using Faiss to around 85 to 95% using Qdrant, and the users are really happy as they are getting suggested really good schemes that would take a lot of time to find.

The file system lock in Qdrant prevents the API and scripts from hitting it directly, and to surpass this limitation, I have to run Qdrant client as a service, which incurs additional costs for running it continuously, so if something about that could be done, it would be really amazing.

Qdrant has been really good apart from the file system lock issue that I have faced, which I had to overcome by building a Docker service to run Qdrant, so apart from that, everything has been really good with Qdrant.

I have used it for the past six months.

Qdrant has been really good and very stable despite the file lock system.

When Qdrant is deployed in Docker, it scales really fast, and you can assign multiple CPUs to enhance performance.

I first started experimentation with Faiss because it does not allow for metadata storage or any additional columns along with the dense embeddings, and I was suggested by my senior that I could use Qdrant as another vector store which allows us to overcome the limitations put forth by Faiss.

I first started with Faiss and even evaluated PGVector before choosing Qdrant.

My advice to others looking into using Qdrant is to go ahead and use it.

Qdrant is really good, and my additional thought is to go ahead and use it. I gave this review a rating of 9.

My primary use cases for Qdrant are legal and educational.

The most valuable feature I have found in Qdrant is the sample code. I think they have good examples that make it developer-friendly.

Using Qdrant's hybrid search capability has improved my search results. The ability of Qdrant to handle high-dimensional vectors for my AI projects is pretty fast, and I think it's the best we have used so far. That's why we continue using it and did not check other options anymore.

The configuration of Qdrant is okay. For a developer, it was easy to set the product up and to use it.

I should check if real-time data updates in Qdrant have helped improve my models, as I don't even know they have that feature.

A lot of our work is agentic right now, and we have also segmented the content to be logical, so there's not a lot of vector search anymore. I haven't really thought of any additional features that would make Qdrant closer to a perfect score.

I have been using Qdrant for two years.

I would rate Qdrant's technical support as community-driven. There's community support since we're not paying anything, and it's more the community support for it. It's open source, so we house it on our server.

I think they provide enough information on the internet, and I am satisfied with it. They explain it well.

Positive

I switched from Faiss because it's open source and there's not a lot of support. We were worried that moving forward, maybe no one will maintain it, so it's just good for experimenting.

The configuration of Qdrant is okay. For a developer, it was easy to set the product up and to use it.

Using Qdrant is free. We house it and have a VM where we just installed it on the VM.

Before finally choosing Qdrant, I did evaluate other options, but that was a long time ago, and I don't know what the state of vector databases is now.

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.