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 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.
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.
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.
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...
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 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.
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.
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.