For small data, just trust @qdrant_engine ! All types of @boardyai embeddings are stored in Qdrant. We have ~60M points (growing daily) and at 150 req/s we see <100ms. If on their managed infra, just need to scale smartly time to time otherwise 0 issues.
brandCooling
Qdrant on X
The largest group, 16 people, report Qdrant running well in their own stack — production, laptops, robots; 13 praise the team and 8 are impressed by its compression. Complaints target how results are presented, re-embedding and data sync.
First written 27 Oct · what changed · from 88 posts by 69 people
Tracking posts that say “@qdrant_engine” or “qdrant”
Track this for your marketPosts, last 24h
10
−37%vs. previous 24h
Posts, last 7 days
118
41 in the last 72h
Velocity
17/day
7-day average
Momentum
−41%
Last 24h vs. a normal day this week
Posts per day, last 30 days
as of Nov 3, 09:00 UTCWhat changed
as of 27 Oct · checked once a monthFirst written 27 Oct. When what people say changes, it shows here.
Tone· 48 posts from 41 people· written 27 Oct
How do people feel about Qdrant?
The largest group of the 41 people posting about Qdrant, 16, report it running well in their own stack — in production, on a laptop, on a robot — and see no reason to switch; behind them 13 praise the product and its team, and 8 are impressed by how far its compression shrinks vectors.
People who describe running Qdrant in their own stack describe it working. One user says a collection of about 60M points at 150 requests a second stays under 100ms, with no issues once managed infrastructure is scaled; others run it self-hosted for a RAG pipeline, on a DGX Spark at home so documents stay local, or on a Raspberry Pi inside a Hugging Face Reachy Mini to give a robot memory. A PHP developer contributed the Qdrant integration for a RAG stack, and one side-project builder says there is "no going back".
Praise is for the team and its published work as much as the software: the DevRel team, a beginner course, and docs that ship an agent prompt. 8 people are impressed by compression — 21x smaller vectors at 99.9% of baseline quality, 77x less RAM for a 5% drop — and 5 welcome native BM25 in release 1.20 as "bm25 without the sparse pipeline". 3 are satisfied with reservations, naming agent memory, source provenance and the learning curve as work left to the application.
- Runs well in my own stack18
- Praise for it and its team14
- Impressed by compression8
- Loves the built-in BM255
- Satisfied with reservations3
See 5 of 48 postsHide the posts
Inside the @huggingface Reachy Mini is a Raspberry Pi. It could hear, see and answer. It could not remember. So we gave it a memory on the robot itself: people, conversations, what it saw today. @qdrant_engine link
The fine folks at @qdrant_engine are doing great work with Qdrant Edge to make vector search accessible on edge devices, such as the @huggingface Reachy Mini! Great for memories, as they show below! Check it out.
77x less RAM for a 5 percent quality drop is a trade I would take instantly I keep hitting the wall on an 8gb laptop gpu where the model fits but nothing else does, so embeddings going from 30gb to 0.4gb is the part that actually changes what you can run at home
bm25 without the sparse pipeline? that's the kind of update i didn't know i needed until now.
5 of the 48 posts behind this answer, one per person. The other 43, and every new one as it’s posted, come with tracking. Get early access
Pain points· 18 posts from 15 people· written 27 Oct
What do people complain about with Qdrant?
The biggest complaint group, 5 people, says Qdrant's published results oversell; next, level at 3 people each, swapping embedding models means re-embedding everything, and keeping a collection in step with a source of truth takes a queued job.
The biggest group is about the claims more than the software. People object that the 1-bit scoring path is documented as following RaBitQ "as-is" while the promotion calls it TurboQuant, and that turbo8 ships with no independent benchmarks yet still needs the original vectors stored, so the compression buys speed by keeping two copies. Others say chunk-level scores can flatter a chunking change and want scoring on whether the answer lands in the top-k.
Swapping the embedding model and keeping data in sync are level, 3 and 3 people. A new model means re-embedding the whole collection, because vectors from different models are not comparable; at the same dimension a stale collection silently returns garbage. Inline deletes mean slow requests and a "half-deleted state", with a source spread over Mongo, Qdrant and S3 as the example, and resends through the official store mint new ids and add duplicate points.
Level at 2 people each: slow first queries while the index builds, and filtered or paged searches coming back empty without an error.
- Published results oversell5
- Re-embedding when you change models3
- Deletes and resends leave data out of sync3
- Slow queries while the index warms up3
- Filtered and paged searches come back empty2
- Memory settings catch you out2
See 5 of 18 postsHide the posts
Qdrant's own docs say: "The 1-bit scoring path follows RaBitQ as-is, without specific modifications." But when promoting these results, RaBitQ disappears and everything becomes "TurboQuant." This is misleading. Readers shouldn't have to dig through technical docs to find the true technique that brings the benefits. link
Qdrant ships turbo8 claiming 2.4× float16 speed with 80% storage cut. No independent benchmarks yet, and you still need to store the original vectors. The quantization buys retrieval speed by keeping two copies.
If you ever swap embedding models you have to re-embed the whole collection, vectors from different models aren't comparable. Putting the model name in the qdrant collection name saves a headache.
I keep going back to my own app and making it harder to break , improving it to the best of what I can , This time I worked on :- 1. Source deletion as a queued cascade A source lives in Mongo, Qdrant, and S3, and chats reference it. Deleting inline means slow requests and half-deleted state on failure. So the API now marks it "deleting" (hidden from the library instantly) and enqueues a BullMQ job: pull it from every chat -> lock any chat left with no sources -> delete vectors -> delete chunks -> delete the file -> delete the record Two decisions matter here. Every step is idempotent, so BullMQ can retry without harm. And the record is deleted last, because it's the only thing that tells a retry what's left to clean up. Chats that lose all their sources become read-only. The UI shows a banner and disables the input, instead of erroring on retrieval. 2. SSRF protection on pasted URLs My server fetches whatever link a user gives it, so a crafted URL could reach cloud metadata or internal services. The guard allows only http and https, resolves the hostname via DNS itself, and rejects the request if any resolved IP is private, loopback, link-local, or reserved. The worker repeats the check right before fetching, which narrows the DNS-rebinding window. It has to check the resolved IP. A hostname blocklist misses link pointing at 10.0.0.5. 3. Sessions and auth Short-lived access token (Bearer) plus a rotating refresh token in an httpOnly cookie A type claim in each token, so a refresh token can't be used as an access token A silent refresh in the axios interceptor. Concurrent 401s share one in-flight refresh, so ten failing requests don't trigger ten refreshes Duplicate sign-ups return the same response as a failed login, so emails can't be enumerated Auth failures return 401, not 400. My frontend only redirected to login on 401, so expired sessions used to get stuck 4. Cursor pagination that survives live data Offset pagination duplicates or skips rows when new items arrive mid-scroll. I moved to cursor-based pagination. The cursor encodes the last row's createdAt and _id, and the query seeks past it (a keyset query), so it never counts or skips rows: filter.$or = [ { createdAt: { $lt: cursor.createdAt } }, { createdAt: cursor.createdAt, _id: { $lt: link } }, // tie-breaker ]; .sort({ createdAt: -1, _id: -1 }).limit(limit + 1) Fetching one extra row tells you whether another page exists. The status poller also merges updates into the loaded list instead of replacing it, which fixed a bug where polling wiped out pages the user had scrolled to. 5. What users feel Rename, pin, and delete for chats. Rename and delete for sources, with optimistic updates that roll back on failure Menus rendered through Radix portals, which fixed one that was clipped by a parent's overflow Citations that open the PDF at the cited page, and only the passages the answer actually used Cmd+K search across chats and sources Autoscroll that follows the stream only while you're at the bottom 6. Two bugs worth remembering Rename failed with nothing in the server logs. My CORS allow-list had no PATCH, so the browser blocked the preflight before my code ran. When a request dies silently, check the browser layer first. Rename then returned a 500 on exactly one chat. save() re-validates the entire document, and one old message had empty content from an interrupted generation: await Chat.updateOne({ _id: chatId, userId }, { $set: { title } }); A targeted write touches only what you mean to change. Diagram below, repo in the replies. link
A filtered search that returns zero results does not throw an error. Qdrant 1.19.2 shipped on Oct 5. One fix in the release notes: zero search results when the HNSW entry point does not satisfy the filter. Other fixes in the same release: - MMR candidates were not ordered by vector distance before merge - MMR pagination with offsets - write tearing in Gridstore storages that could corrupt storage In a RAG system, an empty result looks like "no relevant documents." The pipeline just sees an empty context. Nobody gets paged. This is a design view, not a test result. What I would run on every vector-store upgrade: - a small fixed dataset - filtered queries - a known expected hit for each - an assertion that the hit comes back The same suite can run against any adapter, which is what a contract is for. The caveat from the notes: several fixes involve storage consistency. So test your restore path too, not only the version bump. Test filtered queries with a known answer on every upgrade, because the failure is silent. #Qdrant #RAG #VectorSearch
5 of the 18 posts behind this answer, one per person. The other 13, and every new one as it’s posted, come with tracking. Get early access
Alternatives· 11 posts from 9 people· written 27 Oct
What are the alternatives to Qdrant?
No single comparison leads here: Qdrant is weighed against pgvector, turbopuffer and Milvus at level, 2 people each. The pgvector comparison carries the numbers — Postgres with pgvectorscale wins raw throughput on 50M vectors, while Qdrant wins tail latency and builds its index in a third of the time.
The pgvector comparison comes with a benchmark write-up of 50M vectors: Postgres with pgvectorscale reached 471.57 QPS at 99% recall against 41.47 for Qdrant, but Qdrant won on tail latency and built its index in 3.3 hours where Postgres took 11.1 — the number that hurts if you re-index often. A developer choosing for a product had four options run under the same conditions, pgvector, SQL Server, Weaviate and Qdrant, and reported the tool pushed Postgres+pgvector.
Against turbopuffer, one team says its tool-search embeddings "all fit in memory" and never grow, reports under 10 ms latency with Qdrant, and asks whether there is any reason not to move off turbopuffer for small data; the reply is to stay if it fits in memory and you are happy. Milvus comes up from people who moved away from it, one citing memory requirements that were too large.
One person each: swapping Pinecone for Qdrant to keep a workflow private, comparing Qdrant Cloud's free tier with Upstash Vector's, and asking at what scale local faiss stops being enough.
- pgvector3
- turbopuffer3
- Milvus2
- Pinecone1
- Upstash Vector1
- Embedded local search (SQLite-vec, faiss)1
See 5 of 11 postsHide the posts
Postgres with pgvectorscale hit 471.57 QPS at 99% recall on 50M vectors. Qdrant hit 41.47. Then Qdrant won on tail latency. The pgvector-vs-dedicated fight is the wrong fight. 🧵 1/5
The cost nobody screenshots: Qdrant built its index in 3.3 hours. Postgres took 11.1 hours for the same 50M vectors. If you re-index often, that's the number that'll hurt. 4/5
This might be blasphemous but @composio tool search embeddings all fit in memory. They usually don't grow over time, instead replaced with new tool data. @TridhatriV @abiryanii have been playing with @qdrant_engine and our latency looks < 10 ms Is there any reason we should not move them over from @turbopuffer ?
also moved from Milvus to @qdrant_engine
Self-hosted n8n is a solid core, but with Gemini and Pinecone the docs still leave your machine. If privacy's the goal, swapping in Ollama plus Qdrant or pgvector keeps the whole loop local and the workflow barely changes.
5 of the 11 posts behind this answer, one per person. The other 6, and every new one as it’s posted, come with tracking. Get early access
Questions· 8 posts from 7 people· written 27 Oct
What do people ask about Qdrant?
Questions are thin and split: level at 2 people each, people ask how to tune indexing for latency and memory, and how Qdrant compares with other vector databases for a project. The rest are one-off questions about a specific feature.
The tuning questions are both replies to Qdrant's own material. One asks whether any of the 13 configurations in a comparison tested indexed-only search, "trading fresh points for latency", suggesting the 780 ms came from queries hitting segments not yet indexed and falling back to a full scan. The other asks whether background optimization caused a memory spike, or whether it was "pretty chill".
The picking question is someone deciding for a product: four options — SQL Server, Postgres+pgvector, Weaviate and Qdrant — run under the same conditions before choosing, with the tool recommending Postgres+pgvector. Elsewhere someone simply asks whether another user has opinions on Qdrant.
Single questions: whether MTEB multilingual and code scores exist for the quantised model and whether that quantisation covers vision and audio heads, whether BM25 scoring works with any full-text index or only the one Qdrant builds, and whether an RSLM integration is planned.
- How do I tune indexing for latency and memory?2
- Which vector database should I use?2
- How good is the quantised model?2
- Does BM25 work beyond Qdrant's own index?1
- Is RSLM integration planned?1
See 5 of 8 postsHide the posts
The 780 ms most likely comes from queries hitting segments that aren't indexed yet, so they fall back to a full scan. Did any of the 13 configs test `indexed_only` search, trading fresh points for latency?
that drop in latency is huge. did u notice much of a memory spike during the background opt or was it pretty chill?
@gospaceport do you have any opinions on Qdrant?
今開発している製品でベクトル検索を行うにあたって、どのDBを使おうかなと思い、最初はAIにネットを検索してもらったDA表作ってそれでどれか一つ選んで実装すればいいやとおもっていた。選択したのはSQLServer2025、PosgreSQL+pgvector、Weaviate、Qdrantの４つ。生成AIが作ってくるDA表がどうも納得いかないのでちゃんと論点が整理されて、伝えるべきストーリーが伝わるように推敲していたんだけど、だんだん、これ、試しに実装してもらった方が早くね？と思い、元々試していたWeaviate以外の３つも同じ条件で動かしてもらってその結果から選定するDBをきめることにした。これがサクッと日曜日の午前中に思いついて、時間かかるところは指示だけして、ジムに筋トレしにいって帰ってきたら終わってたのでそれをチェックする。Posgre+pgvectorを推してきた。ごちゃごちゃ書いてそれっぽいこと言ってるけど意味わからんかったので、結局なんで？って聞いたらスゲー分かりやすいこといってきたので、それをレポートに書け(笑)って言って終了。
Do you have scores of MTEB multilingual and code benchmark of the quantised model?
5 of the 8 posts behind this answer, one per person. The other 3, and every new one as it’s posted, come with tracking. Get early access
Wishes· 4 posts· written 27 Oct
What do people want from Qdrant?
Wishes are few and specific. The largest group, 2 people, wants control over what an agent's memory keeps and forgets; the rest are single requests — publishing embedding-model benchmarks, and making late-interaction retrieval cheaper.
The memory wish comes from people building agent memory on top of Qdrant. One, describing a robot's on-device memory, says nothing ages out yet and one button wipes it all, and that for a real home device they would add "forget me" and expiry by age, noting that in Qdrant Edge each is a delete by filter. The other says "this week only" is part of a preference worth remembering too — a time-scoped memory.
The remaining posts are each from one person. One asks Qdrant to benchmark several embedding models and list the results on its site, so developers can choose which suits them. Another proposes a middle ground for late-interaction retrieval: single-vector HNSW for recall, then MaxSim over multi-vectors only for the top-k kept on disk, paying late-interaction cost per query rather than per page in RAM, and asks what that adds on chart-heavy pages.
- Control over what agent memories keep and forget2
- Publish embedding model benchmarks1
- Cheaper late-interaction retrieval1
See the 4 postsHide the posts
Mostly by not remembering in the first place: a frame is stored only when the scene changes, at most one every 10 s. Nothing ages out yet, and one button wipes it all. For a real home device I would add "forget me" and expiry by age; in Qdrant Edge each is a delete by filter
“This week only” is part of the preference worth remembering too 😅
It is nice if Qdrant can do the benchmark with several embedding models and list it on the site. It’s easy for developers to choose which one is best for our usage.
The natural middle ground looks like a cascade: single-vector HNSW for recall, then MaxSim over multi-vectors only for the top-k, with those kept on disk. You pay late-interaction cost per query instead of per page in RAM. Curious how much that adds on chart-heavy pages.
In their words
How do people talk about Qdrant?
The phrases people use most, counted once per person.
- 1“vector search”6
- 2“smaller vectors”3
- 3“original vectors”3
- 4“embedding models”3
- 5“retrieval quality”2
- 6“local qdrant”2
- 7“text search”2
- 8“queued cascade”2
- 9“worth remembering”2
Posts are shown the way X shows them. One of them yours? Here’s why it’s shown, and how to take it off.
Also in Vector databases
Get every post about Qdrant, filtered and labelled
This page is the summary. Tracking gives you the stream behind it for any brand, keyword or @mention: each new pain point, request and question as it’s posted, with the spam and promotions already taken out.