# Qdrant > Native vector and hybrid search with Qdrant REST and gRPC clients. 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: ```bash 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: ```python 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. ```bash 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: ```bash 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. [View this page on the web](https://docs.watasu.io/addons/qdrant/)