Deploy and Scale on Qdrant - Vector Search Engine

Vector Search in Production: Scaling, HA & Tuning Guide

info@qdrant.tech (Andrey Vasnetsov) — Wed, 30 Apr 2025 00:00:00 +0000

Vector Search in Production: Scaling, HA & Tuning Guide

What Does it Take to Run Search in Production?

A mid-sized e-commerce company launched a vector search pilot to improve product discovery. During testing, everything ran smoothly. But in production, their queries began failing intermittently: memory errors, disk I/O spikes, and search delays sprang up unexpectedly.

It turned out the team hadn’t adjusted the default configuration settings or reserved dedicated paths for write-ahead logs. Their vector index was too large to fit comfortably in RAM, and it frequently spilled to disk, causing slowdowns.

Data Privacy with Qdrant's Role-Based Access Control (RBAC)

info@qdrant.tech (Andrey Vasnetsov) — Tue, 18 Jun 2024 08:00:00 -0300

Data Privacy with Qdrant’s Role-Based Access Control (RBAC)

Data stored in vector databases is often proprietary to the enterprise and may include sensitive information like customer records, legal contracts, electronic health records (EHR), financial data, and intellectual property. Moreover, strong security measures are critical to safeguarding this data. If the data stored in a vector database is not secured, it may open a vulnerability known as “embedding inversion attack,” where malicious actors could potentially reconstruct the original data from the embeddings themselves.

Choose a Multitenancy Design

info@qdrant.tech (Andrey Vasnetsov) — Tue, 06 Feb 2024 13:21:00 +0000

Choose a Multitenancy Design

Choose a design from the number of tenants, their relative sizes, and their isolation requirements. Start with payload-based partitioning when many tenants share the same collection configuration. Use dedicated shards or collections when a tenant needs different capacity or configuration.

Workload or constraint	Starting design	Main trade-off
Many small tenants with similar data and vector configuration.	One collection with a tenant payload field and index.	Tenants share collection resources and configuration.
A few large tenants and many small tenants.	Tiered multitenancy with shared and dedicated shards.	You must plan shard capacity and tenant promotion.
A small number of tenants need separate collection configuration or collection-level permissions.	Separate collections.	Each collection adds resource and operational overhead.
A tenant’s data must reside on specific nodes.	Custom shard keys and explicit shard placement.	You must manage shard placement and capacity.

These choices can be combined. For example, a custom shard can contain several tenants separated by payload filters.