Qdrant

Qdrant is a Rust vector database for similarity search, sparse-vector retrieval, metadata filtering, and hybrid queries. Applications use the official Qdrant SDKs and native REST or gRPC APIs directly. Watasu does not add an application API proxy. Embedding generation and synchronization with your source database belong to your application. Keep the authoritative messages or documents in your primary store.

Tiers and sizes

Hobby has one peer with network SSD storage. Standard has three peers on distinct workers in one location, with local NVMe. Premium distributes peers evenly across Nuremberg, Falkenstein, and Helsinki, with local NVMe in each location.

CPU, memory, and disk below are per peer. Total physical disk counts all data replicas; it is not the amount of unique source data you can store.

Plan	Peers	vCPU/peer	RAM GiB/peer	Disk GiB/peer	Physical disk GiB
hobby-0	1	1	2	20	20
hobby-1	1	2	4	50	50
hobby-2	1	4	8	100	100
standard-0	3	2	4	50	150
standard-1	3	4	8	100	300
standard-2	3	8	15	200	600
premium-0	3	4	8	100	300
premium-1	3	8	15	200	600
premium-2	6	8	15	200	1200
premium-3	9	8	15	200	1800
premium-4	12	8	15	200	2400

Each peer also has separate snapshot working space equal to its data disk. Indexes, payloads, WAL, replication, and optimization require space beyond raw vectors. Measure your vector dimensions, payload indexes, query concurrency, and ingestion rate before sizing. There is no fixed messages-per-plan promise.

Replication and protection

Standard and Premium default to three shard replicas and two acknowledgements per write. Hobby defaults to one replica and one acknowledgement. These are defaults: you can choose collection-level replication, consistency, sharding, quantization, and index settings through native APIs.

Watasu observes actual shard copies and, when managed placement is enabled, uses native replica operations for automatically sharded collections to reach your configured replication factor and spread Premium copies across the three locations. Copies are transferred before redundant copies are removed. The dashboard reports observed protection separately from the plan topology; an old observation is shown as unknown.

A Premium plan alone does not protect an RF1 collection. Write availability also depends on collection write consistency and request ordering. Replication is not a backup. Qdrant OSS does not automatically reshard existing collections when peers are added; choose shard counts deliberately or reindex into a new collection and switch a native alias.

Native clients and credentials

Create and attach Qdrant with the standard add-on workflow:

watasu addons:create qdrant:standard-0 --app my-app
watasu addons:info ADDON_NAME
watasu addons:wait ADDON_NAME

Attachment variables are QDRANT_URL, QDRANT_GRPC_URL, QDRANT_API_KEY, QDRANT_READ_ONLY_API_KEY, and QDRANT_CA_CERT. Attachment aliases prefix all five names. Credentials are private; never place them in browser code or logs.

Private endpoints require the supplied CA. With the official Python SDK:

import os
import ssl
from qdrant_client import QdrantClient

ca = os.environ["QDRANT_CA_CERT"]
client = QdrantClient(
    url=os.environ["QDRANT_URL"],
    api_key=os.environ["QDRANT_API_KEY"],
    verify=ssl.create_default_context(cadata=ca),
    grpc_port=6334,
    grpc_options={"root_certificates": ca.encode()},
    prefer_grpc=True,
    timeout=30,
)

Use the read-only key for query-only consumers. Native JWT-based granular access is enabled for collection and payload scoping; use Qdrant’s documented token format and keep the signing API key server-side. Watasu does not rewrite SDK calls.

Access is private by default. The public_access setting adds separate public TLS REST and gRPC endpoints shown in the dashboard. Public endpoints still require credentials; private peer communication is never exposed publicly. For public gRPC, use its displayed hostname on port 443 and the normal public CA trust store.

Backups and restore

Watasu captures each shard through native snapshots, streams it to object storage, verifies its SHA-256 after upload, and writes a completion manifest only after every shard is covered. Collection configuration and aliases are included. It records an online capture interval: concurrent writes across different shards do not form one database-wide transaction or a point-in-time recovery position.

Hobby supports manual capture. Standard and Premium additionally schedule daily capture, with catch-up after a missed slot. Restores create a new private, unattached add-on and rebuild replicas before reporting readiness. Local-file import and single-file backup download are not available for this distributed backup format.

watasu addons:backups:capture ADDON_NAME
watasu addons:backups ADDON_NAME
watasu addons:restore ADDON_NAME BACKUP_ID --name search-restored
watasu addons:wait search-restored

Verify collection counts, aliases, payload indexes, and representative searches before switching your applications. Writes accepted after the backup interval are not included. The generic promotion workflow swaps attachments and retires the source add-on; treat promotion as a separate destructive decision.

Capacity and lifecycle

Increase capacity from the add-on Settings page or CLI:

watasu addons update ADDON_NAME --plan premium-2
watasu addons update ADDON_NAME --public-access true
watasu addons update ADDON_NAME --backup-retention-days 14

A larger plan must retain at least the current peers, locations, CPU, memory, and disk per peer. Each replacement gets a new disk. Watasu transfers and verifies its shards before retiring the old peer. Interrupted operations resume their recorded layout. Billing moves to the new plan after the requested capacity is ready. Existing collections retain their shard counts. Reducing capacity requires a separate replacement and data migration sized for the destination.

A peer that remains unavailable for ten minutes can be replaced when the surviving cluster has quorum and usable shard copies. Recovery does not recreate lost data: a lost last copy or lost consensus requires a recovery decision using backups or the authoritative source. During membership changes, protection can temporarily be lower than the final plan; the dashboard shows observed protection.

Custom shard keys and their per-key replica counts remain customer-managed. Backups preserve those keys and replica counts, and peer replacement preserves copies before retirement. Use native placement APIs to arrange custom shards across locations; automatic placement follows collection defaults for automatically sharded collections only. You can pause it with --managed-placement false.

Backup retention is configurable from 1 to 35 days (7 by default). Incomplete uploads are pruned too; an unfinished replacement restore protects its source backup. Deleted add-ons retain their backup objects for the retention window.

Certificate renewal triggers peer-by-peer restarts with replica checks. API-key rotation uses Qdrant’s native keys and refreshes attachment credentials. Native keys do not provide an overlap period: clients can see authentication failures during rotation, and JWTs signed with the old admin key become invalid.