Hello Qdrant team!
We have a philosophical question about Qdrant. We are planning to store 1B objects in a qdrant collection, with vectors and a small payload comprised of our objects' labels as we already discussed. The use-case is of course to do similarity search between the objects and constraint this search using the labels.
But we would also like to have a reference database for our objects, to query them (without similarity search), and have more contextual data attached (creation dates, user ids, nested data and lot more).
We were wondering if you think Qdrant could be suitable as a database + a vector search engine, and is this a use-case for which you will build features in the future (more payload types, filtering performance optimizations…). Or would you advice to use a secondary database and focus on using Qdrant as a vector search engine in sync with a primary storage?

If you need those payloads in qdrant for faster retrieval, then it should be fine. But I would not recommend to use it as the "source of truth" type of the database. We are not providing transaction guarantees and our architecture is pretty heavily biased towards availability over consistency on CAP theorem

I think we do lie on the "qdrant for faster retrieval" use-case. Consistency is not top priority given we will have few access, and probably not concurrent. Would you say it will be possible in the future that you enrich the filtering system to have queryable nested object, filters on lists, and other data types similar to what we can have using Elasticsearch ?

I have a follow up to this philosophical question. Say we use qdrant as only the vector storage and a second relational database as a source of truth. If a user deletes a record in the source of truth relational database, does anyone have advice or recommendations for propagating that to qdrant so that the record no longer appears in results of queries?