Qdrant on a VDS: A High-Performance Vector Database

What Is Qdrant?

Qdrant is a high-performance open-source vector database written in Rust. It supports billions of vectors, flexible metadata filtering, and runs as a standalone service with REST and gRPC APIs.

Installing via Docker

docker run -d \
  --name qdrant \
  -p 6333:6333 \
  -p 6334:6334 \
  -v qdrant_storage:/qdrant/storage \
  --restart always \
  qdrant/qdrant

Working with Qdrant from Python

>pip install qdrant-client

from qdrant_client import QdrantClient
from qdrant_client.models import Distance, VectorParams, PointStruct

client = QdrantClient(host="localhost", port=6333)

# Create collection
client.create_collection(
    collection_name="kb_articles",
    vectors_config=VectorParams(size=768, distance=Distance.COSINE)
)

# Add vectors
client.upsert(
    collection_name="kb_articles",
    points=[
        PointStruct(id=1, vector=[0.1]*768, payload={"text": "Installation VDS"}),
    ]
)

# Search
results = client.search(
    collection_name="kb_articles",
    query_vector=[0.1]*768,
    limit=5
)
for r in results:
    print(r.payload["text"], r.score)

LangChain Integration

from langchain_community.vectorstores import Qdrant
from langchain_community.embeddings import OllamaEmbeddings

embeddings = OllamaEmbeddings(model="nomic-embed-text")
db = Qdrant.from_documents(
    docs,
    embeddings,
    url="http://localhost:6333",
    collection_name="my_docs"
)
retriever = db.as_retriever(search_kwargs={"k": 4})

Common errors when working with Qdrant

«Wrong input: Vector dimension error»

Bad request: Wrong input: Vector dimension error: expected dim: 768, got 1536

A collection's vector dimension is fixed when it is created via VectorParams(size=...) and cannot differ from the dimension of the embeddings you actually send. This error shows up when you switch the embedding model (say, from 768 dimensions to 1536) without recreating the collection.

The container starts but port 6333 is unreachable from outside

curl: (7) Failed to connect to IP port 6333: Connection refused

Check that the port is actually published in the run command (-p 6333:6333) and not just declared in a config file, and that the VDS firewall is not blocking external connections to that port.

Data disappeared after recreating the container

If the container runs without a volume for /qdrant/storage, every collection lives only inside the container and is lost when it is removed. Check for the -v qdrant_storage:/qdrant/storage flag in the run command before loading production data into the database.

The gRPC client cannot connect even though REST works

grpc._channel._InactiveRpcError: failed to connect to all addresses

Qdrant exposes two independent ports: 6333 for REST and 6334 for gRPC. If the client library is configured for gRPC but only port 6333 is published and open, the connection fails exactly this way. Check which protocol your client actually uses and open both ports if gRPC is needed.

Qdrant, Chroma, and pgvector: which to choose

All three stores solve vector search, but they are built for different data volumes and different levels of integration with an existing database.

When Qdrant is overkill

The power of a production-oriented database written in Rust becomes overhead wherever a much simpler solution would do.

• A prototype or hobby project with a couple thousand documents — running a separate service for that volume is not worth it; Chroma's embedded mode is enough
• Data already lives in PostgreSQL and vector search is just an add-on — pgvector is the more logical choice, without extra infrastructure
• The VDS is already tight on resources — Qdrant as a separate process needs additional memory on top of the application
• There is no need for filtering on complex metadata during search — a simple vector index in the existing database is enough
• The team is not ready to administer yet another standalone service with its own lifecycle and backups

Verifying the result

Before connecting production traffic, check not just the search itself but how well the data survives a restart.

1. Create a collection and add a test set of vectors
2. Run a search and confirm it returns the expected nearest neighbors with a reasonable score
3. Open the /dashboard UI and check that the collection and its point count display correctly
4. Restart the container and confirm the data is still there
5. Check both ports — 6333 and 6334 — if the application uses both REST and gRPC

Related: a simpler database to start with — Chroma DB on a VDS, a full comparison of the options — vector databases, search right inside PostgreSQL — pgvector.