Qdrant

AddisDB talks to Qdrant over its REST API. Type a bare collection name to page through its points, paste a raw JSON body, or write an explicit method and path for anything the shorthands do not cover.

Who it is for

Qdrant is a dedicated vector database written in Rust, built around filtered search: rich payload conditions are applied during the vector search rather than after it, so filtered queries stay fast instead of degrading into a scan.

That is done with a payload index alongside the HNSW graph, so a condition like tenant = X prunes the graph traversal itself. Without a payload index on the field you filter on, the same query falls back to filtering results after the fact — which is where the recall complaints come from.

Choose it when vectors are the primary workload rather than a column on an existing table — large corpora, heavy metadata filtering, or a retrieval service you want to scale independently of your application database.

Set up the server

1. Qdrant Cloud: create a cluster, then generate an API key. The key is shown once.
2. Copy the cluster URL. Cloud clusters serve HTTPS on port 6333.
3. Local: docker run -p 6333:6333 -p 6334:6334 qdrant/qdrant — no API key needed by default.
4. Create a collection with the vector size and distance metric your model uses.
5. Add a payload index for every field you plan to filter on; that is what keeps filtered search fast.

# A local Qdrant in one line
docker run -p 6333:6333 -d qdrant/qdrant

Connect from AddisDB

1. New Connection → Qdrant under Vector / AI. Port prefills to 6333.
2. Enter the host, and paste your API key into the API key / token field (leave it blank for a local instance).
3. Collection is optional — set one as the default for raw-body queries, or leave it blank.
4. For Qdrant Cloud, set the port to 6333 and SSL mode to require.
5. Test, then Save.

Port 6333 is the REST API; 6334 is gRPC. AddisDB speaks REST, so 6333 is the one that matters here.

How to query it

// Just a collection name — scrolls its points
documents

// A raw body against the default collection
{ "limit": 50, "with_payload": true, "with_vector": true }

// Or an explicit request
GET /collections

Scrolling and searching are different endpoints for different questions. A scroll walks the collection in id order and is what you want for browsing; a search takes a query vector and returns neighbours with scores. The explicit form reaches either.

// Nearest neighbours, filtered by payload
POST /collections/documents/points/search
{ "vector": [0.01, -0.2, …], "limit": 10, "with_payload": true,
  "filter": { "must": [ { "key": "tenant", "match": { "value": "acme" } } ] } }

GET /collections/<name> is worth running on any collection you did not create: it reports the vector size, distance metric, point count and which payload fields are indexed — the four facts that explain most surprises.

What AddisDB gives you

• Collections listed in the sidebar.
• Points flattened into the grid — payload keys become columns alongside id and score.
• The Vectors view for seeing how your embeddings cluster, and the JSON tab for the raw response.
• Read-only enforcement — PUT, PATCH and DELETE are blocked, and only read endpoints such as points/scroll and points/search pass through POST.
• Point counts per collection feeding the size alerts.
• Query tabs and history, and ⌘K search across every connection.