Qdrant

Qdrant is a vector similarity search engine. It stores embeddings with JSON payloads and returns nearest neighbours fast, with payload filters applied during the search rather than afterwards.

Overview

Each instance runs the open-source Qdrant server as a single node, with telemetry turned off. It serves a REST API and a gRPC API, both on port 443 behind TLS (gRPC on its own -grpc hostname), and both require the instance’s API key. The key has full access to every collection.

Qdrant at a glance, from the engine catalogue

Status	Available
Category	Vector
Versions	1.19 (newest is the default)
Protocol and port	HTTPS on 443; also grpc on 443 (host qdrant-7f3k-grpc.us-east.databasezy.com)
Runtime	Single-node engine (qdrant/qdrant)
Backups	collection snapshots (snapshot API)
Point-in-time recovery	No
Pause	Scale to zero
Free plan	Yes (size f0)
Licence	Apache-2.0

When to use it

• Retrieval for LLM applications (RAG) and semantic search over your own embeddings.
• Recommendations and similarity search with filters on metadata such as tenant, language or date.
• Hybrid search that combines dense and sparse vectors.

Qdrant does not create embeddings: compute them with your model of choice and send the vectors. For keyword search with typo tolerance, use Meilisearch.

Create an instance

Portal

1. Open the portal and choose New instance.
2. Pick Qdrant and a version (1.19).
3. Choose a size and region. On the Free plan the size is f0. Secure placement is listed only after your organization has signed the BAA.
4. Check the hourly price and monthly estimate, then confirm. The Connect tab fills in when the instance is ready.

CLI

shell

zb instances create --engine qdrant --engine-version 1.19 \
  --size s1 --region us-east --name qdrant-demo --wait
# On the Free plan, use --size f0

# Reveal the credentials once and store them in your secret manager
zb instances credentials reveal qdrant-demo

API

shell

curl -sS https://api.databasezy.com/v1/orgs/$ZB_ORG/projects/$ZB_PROJECT/instances \
  -H "Authorization: Bearer $ZB_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
  "engine": "qdrant",
  "engine_version": "1.19",
  "size": "s1",
  "region": "us-east",
  "name": "qdrant-demo"
}'

The response is 201 with the instance in status requested, or 202 when a team approval policy applies. See the REST API reference.

Connect

Endpoint and credentials

How a Qdrant instance is reached: host, ports, TLS and credentials

Host	qdrant-<id>.<region>.databasezy.com, for example qdrant-7f3k.us-east.databasezy.com
Port 443	REST API
Port 443	gRPC API over HTTP/2 , on host qdrant-7f3k-grpc.us-east.databasezy.com
Single-IP regions	Single-IP regions use 8443 for HTTP engines instead of 443. The portal Connect page always shows the right port.
TLS	Required on every port; plaintext is refused. Verify the server: https:// (or the driver's TLS flag) with normal certificate verification; the certificate is publicly trusted.
Credentials	One generated API key (token) with no username, presented as api-key header (or Authorization: Bearer) on REST and gRPC. Shown once at creation; reveal or rotate it from the Connect tab.

Send the key in the api-key header (or Authorization: Bearer) on REST, and as the api-key metadata on gRPC; the official clients do this when you pass api_key. Keep :443 in the REST URL: the Python client otherwise assumes Qdrant’s default port. gRPC clients connect to the -grpc hostname, also on port 443.

Drivers and clients

Qdrant listens on port 443 (REST API); port 443 on qdrant-7f3k-grpc.us-east.databasezy.com (gRPC API over HTTP/2). Versions: 1.19. Replace the example host with the one on your instance's Connect tab; credentials are shown once at creation.

Connection URI

https://qdrant-7f3k.us-east.databasezy.com:443

Python

vectors.py

import os
from qdrant_client import QdrantClient, models

# REST over TLS. Keep the explicit :443: without it the client assumes port 6333.
client = QdrantClient(url="https://qdrant-7f3k.us-east.databasezy.com:443", api_key=os.environ["ZB_TOKEN"])

# gRPC lives on its own hostname, also on port 443:
# QdrantClient(url="https://qdrant-7f3k-grpc.us-east.databasezy.com:443", grpc_port=443,
#              prefer_grpc=True, api_key=os.environ["ZB_TOKEN"])

client.create_collection(
    "docs", vectors_config=models.VectorParams(size=384, distance=models.Distance.COSINE)
)
hits = client.query_points("docs", query=[0.1] * 384, limit=3).points
print(hits)

Tested with: Qdrant 1.19 · qdrant-client 1.15

TypeScript

vectors.ts

import { QdrantClient } from "@qdrant/js-client-rest";

const client = new QdrantClient({
  url: "https://qdrant-7f3k.us-east.databasezy.com:443",
  apiKey: process.env.ZB_TOKEN,
});

console.log(await client.getCollections());

Tested with: Qdrant 1.19 · @qdrant/js-client-rest 1.15

Rust

main.rs

use qdrant_client::Qdrant;

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    // The Rust client speaks gRPC, so it uses the gRPC hostname (also port 443).
    let client = Qdrant::from_url("https://qdrant-7f3k-grpc.us-east.databasezy.com:443")
        .api_key(std::env::var("ZB_TOKEN")?)
        .build()?;
    println!("{:?}", client.list_collections().await?);
    Ok(())
}

Tested with: Qdrant 1.19 · qdrant-client 1.15 (gRPC)

HTTP / curl

shell

curl -sS https://qdrant-7f3k.us-east.databasezy.com:443/collections -H "api-key: $ZB_TOKEN"
curl -sS https://qdrant-7f3k.us-east.databasezy.com:443/collections/docs/points/query -H "api-key: $ZB_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"query": [0.1, 0.2, 0.3], "limit": 3}'

Tested with: Qdrant 1.19 · curl 8

Official clients exist for Python, TypeScript and JavaScript, Rust, Go, Java and .NET. The REST client is simplest through firewalls; gRPC is faster for bulk upserts and large result sets.

See Connecting to Databasezy for the CA bundle, the IP allow-list and credential rotation, which work the same for every engine.

Migrate in

Where you can migrate a Qdrant database from, how, and whether continuous sync is available

Source	How	Continuous sync	Guide status
Self-hosted server	Connection string, Local tools (zb migrate --from local)	No	Available
Another Databasezy instance	Instance to instance	No	Coming soon · phase 2

To move a collection from another Qdrant server, create a snapshot on the source and upload it to the new instance, which recovers the collection from it:

shell

curl -sS -X POST "https://qdrant-7f3k.us-east.databasezy.com:443/collections/docs/snapshots/upload?priority=snapshot" \
-H "api-key: $ZB_TOKEN" -F "[email protected]"

Use the same major and minor Qdrant version on both sides, or re-upsert the points with a client if versions differ.

How migrations work explains preflight, verification and cutover, and engine conversions covers moves between compatible engines.

Backups and restore

Backups use Qdrant’s snapshot API: each collection (vectors, payloads and indexes) is snapshotted from a consistent view of its segments and copied to object storage. Collections are snapshotted one after another, so a backup is consistent per collection. A restore uploads the snapshots into the running instance, creating or replacing each collection. There is no point-in-time recovery.

Qdrant backups use collection snapshots (snapshot API). They run inside the instance's namespace, stream straight to the cell's object storage and are checksummed on upload. How often they run and how long they are kept follows your plan's backup policy. A backup is always taken before a resize or a version upgrade.

Point-in-time recovery is not available for Qdrant. A restore returns the data as of a scheduled or manual backup. Restores create a new instance by default and leave the original untouched; an in-place restore asks you to type the instance name and takes a pre-change backup first.

shell

zb backups create qdrant-demo --label before-release      # manual snapshot
zb backups list qdrant-demo
zb backups restore qdrant-demo <backup-id> --name qdrant-demo-restore

Pause and scale to zero

Qdrant can scale to zero. A paused instance has no running pods and bills no compute; its storage and backups are kept and billed as usual. Connections are refused until you resume it. On the Free plan an instance pauses by itself after 15 minutes without connections and wakes on the next one; the gateway holds that connection for up to 30 seconds while it starts.

shell

zb instances pause qdrant-demo
zb instances resume qdrant-demo

See Pause and resume for schedules, wake times and billing while paused.

Limits, versions and lifecycle

Versions and lifecycle

• Supported versions: 1.19 . New instances default to 1.19, the only version offered.
• Minor and patch releases are applied for you in the maintenance window, always after a pre-change backup.
• New majors are added within 60 days of the upstream release. A major reaches end of life on Databasezy six months after upstream ends support, with notices 90, 30 and 7 days ahead.

Sizes and limits

Qdrant runs on every size, including the Free plan's f0. The size sets the CPU, memory, storage ceiling and connection limit; the gateway refuses connections over the limit with a protocol error. Storage grows in steps up to the ceiling, and you can resize at any time.

Sizes available for Qdrant: vCPU, memory, storage ceiling, connection limit and monthly price

Size	vCPU	Memory	Max storage	Max connections	≈ $ / month
f0	0.063	512 MiB	1 GB	20	Free
s0	0.25	1 GiB	20 GB	60	$10
s1	0.5	2 GiB	50 GB	100	$15
s2	1	4 GiB	200 GB	200	$60
m2	2	8 GiB	500 GB	400	$110
m4	4	16 GiB	1 TB	800	$210
l8	8	32 GiB	4 TB	1,500	$410
l16	16	64 GiB	8 TB	3,000	$960
xl32	32	128 GiB	16 TB	5,000	$1,870

Full details, including hourly prices and burst CPU, are in the size catalogue; plan quotas are in limits and quotas.

By default vectors and the HNSW index are held in memory, so memory decides how many vectors fit. For large collections, store vectors on disk (on_disk: true) or turn on scalar or binary quantization to cut memory use. REST request bodies are limited by Qdrant’s max_request_size_mb (32 MB by default); batch large upserts.

Licence

Databasezy runs Qdrant under the Apache-2.0 licence, as listed in the engine catalogue. Your data and schemas are yours whatever the server's licence; the licence governs the server software we run.

Qdrant is Apache-2.0. Qdrant Cloud features such as hosted inference and the managed cluster are not part of the open-source server and are not included.

Security

• TLS on every connection. TLS 1.2 is the minimum and TLS 1.3 is preferred; plaintext is never offered. Verify the server, not just the encryption: use HTTPS with certificate verification. See TLS and the CA bundle.
• IP allow-list. The gateway checks the client address before authentication, on every plan. Manage it under Network → Allow-list in the portal or with PUT /v1/orgs/{org}/instances/{id}/network.
• Credentials. Generated inside the cell, shown once, never stored by the control plane. Rotate them with an overlap window so nothing breaks.
• Secure hosting. Secure placement (HIPAA-ready) is a per-instance option once your organization has signed the BAA: dedicated nodes, customer-managed keys and immutable backups. See Secure hosting and the BAA.
• Staff access. Databasezy staff cannot read your data without a grant you issue. See data confidentiality.

FAQ

REST or gRPC?

Both reach the same data. Start with REST; point a gRPC client (the Python client with prefer_grpc=True, or the Rust or Go clients) at the -grpc hostname on port 443 when you need higher upsert throughput.

Can I give a front end read-only access?

No: the instance has one API key with full access. Keep it on your servers and query Qdrant from your backend.

Is Qdrant on the Free plan?

Yes, on the f0 size. The f0 memory suits small collections and prototypes.