On 4 April 2025, Charlie Greenman published how Razroo left Pinecone for Qdrant. The post is first-party. The timings in it are Razroo’s measurements, and the post does not show the traces behind them.
Razroo builds AI simulations and synthetic data. Charlie writes that an average month is 50 million to 100 million AI requests, plus close to 200 million reads and 200 million writes. A slow vector call sits on every one of those requests.
They had started on Pinecone, including Pinecone Serverless, and built the consumer app there. Pinecone’s namespaces made it hard, in their telling, to query across the data at a speed they could afford. Indexing already ran off the request path. S3 files and Step Functions do that work, which they say saves about one to two seconds on the API.
Two model changes before the data move
Qdrant has no namespaces. A filter reads metadata on the point. They created a payload index on orgId as a keyword field, then filtered on that field instead of picking a Pinecone namespace.
Qdrant point ids are UUIDs or numbers. Pinecone ids were strings. Charlie calls the id change the hard part. They wrote a UUID onto every S3 file and every DynamoDB row, so they can still update or delete a vector. Number ids lost because of write volume and concurrency. A UUID was how they avoided collisions.
He says the Step Function swap itself is a small code change once those two models exist. There is no field-by-field client map in the post.
What they say got faster
The outcome line says API call times fell by up to 95%, at a volume of up to 100 million requests a month. Later he says the average API time dropped by 1 second.
The AI assistant is a separate pair of numbers. With Pinecone, calls were about 2.5 seconds, and he also says Pinecone added 1.5 seconds, which was too slow to ship. With Qdrant, the same assistant path came in within 1 second. Vector reads across millions of items landed in 80 ms to 150 ms. He says that speed is why the assistant could go to production.
Those figures do not all describe the same measurement. Up to 95%, a 1 second average drop, and 2.5 seconds down to within 1 second can all be true for different routes. The post does not show which route produced 95%. I would not merge them into one speedup.
He also estimates close to 2,000 hours of compute a week, and a wider range of 700 to 2,800 hours, from the slower database multiplying out across datasets. That is his arithmetic, not a cloud bill. There is no dollar figure.
What I would copy
Change ids and tenancy before you copy points. Razroo had to stamp UUIDs through S3 and DynamoDB because Qdrant will not take an arbitrary string id. A namespace in Pinecone becomes a payload field plus an index. The Pinecone → Qdrant playbook flags missing namespaces as a silent success. Filter on orgId in a test query that used to be a namespace lookup, and compare counts.
Keep the assistant latency separate from the bulk API average. They needed the assistant under a second. The 95% line does not prove that by itself.
If you index from object storage through a queue, point that worker at Qdrant only after the id column exists. Otherwise you write vectors you cannot delete.