SaaS software vendor HubSpot has described how its semantic search platform grew from a proof of concept into an internal service that now manages more than 20 billion vectors across 38-plus teams. The company says the system now supports agents, RAG, and contact deduplication, and that the increase in agent usage has made retrieval quality and latency more important than before.
The post on HubSpot's site explains that the platform, called VaaS or Vector as a Service, sits in front of Qdrant and provides access control, embeddings generation, data versioning, and feedback collection. HubSpot says it chose Qdrant because it can run on-premises, supports features such as named vectors, hybrid search, multi-stage querying, and weighted reranking, and offers cost controls including quantisation and on-disk storage.
HubSpot also says it runs Qdrant in-house because that lets it integrate with internal tracing, cost tracking, rate limiting, scaling, and security tooling, while keeping control over customer data. The company says the current platform spans more than 200 indexes, 140-plus clusters, five regions, and two environments, with write traffic peaking at 100,000 requests per second.
In the post, Oleg Tereshin and Xin Liu write that the early setup was built with Helm and a small number of consumers, but that manual management became harder as the fleet grew. They say the team moved to an internal Kubernetes Operator framework because Helm could not make API calls, auto-scale from external metrics, or handle more complex state-aware lifecycle work.
"Manual operations don't survive growth."
-- Oleg Tereshin and Xin Liu That move shifted cluster management into what HubSpot calls Translators, which reconcile the desired and actual state of the system every 60 seconds. The post says this approach now automates cluster creation and decommissioning, shard movement, and replication recovery, while also reducing operational load on the team.
The same pressures show up in other vector search systems. Qdrant's own large-scale guidance focuses on tuning for hundreds of millions of vectors while keeping latency and accuracy in production range, which reinforces HubSpot's point that scale is as much about operations as it is about retrieval quality.
Other practitioners have also landed on similar lessons. A LinkedIn post from Pinecone describes a jump from 40 million to 600 million vectors, with advice that recall must stay high, storage and compute should be separated, and reliability should be treated as a feature, while a separate production write-up on vector search recommends versioned indexes, filter-aware design, and careful monitoring of recall and latency.
"Recall is king."
-- Pinecone post on LinkedIn Those themes match HubSpot's emphasis on balancing shard placement, avoiding memory skew, and using automation to keep operational work under control. The company says some collections contain billions of points, and that even one imbalanced shard can force a cluster to scale before it really needs to.
HubSpot also says the shift reduced cluster spin-up time from hours to minutes and removed the need for standby clusters. It adds that the same reconciliation model now handles horizontal scaling, shard rebalancing, and replication recovery, which makes the platform easier to operate as demand rises.
The broader pattern is visible across the vector search market, where teams are increasingly trying to simplify retrieval systems without giving up performance. InfoQ has recently covered vector search additions in OpenSearch, PlanetScale, and AlloyDB, all of which point to the same pressure: developers want semantic retrieval close to their data, with enough control to tune cost and latency.
For HubSpot, the main point is not that vectors are new, but that the surrounding infrastructure now has to behave like a mature platform service. The post makes clear that once retrieval became central to multiple AI products, the database itself was only part of the problem. The harder task was building enough automation around it to keep the system stable as demand kept rising.